DEV Community: arnica-simon

How to Evaluate a Static Application Security Testing (SAST) Solution

arnica-simon — Tue, 14 Nov 2023 19:38:53 +0000

TL;DR

Static Application Security Testing (SAST) is a foundational building block of an Application Security program. In this blog, we explore what qualities you should look for when selecting your SAST tools.

How to evaluate a Static Application Security Testing (SAST) solution

Static Application Security Testing (SAST) is a type of software testing that occurs relatively early in the software development lifecycle (SDLC). SAST scanners analyze an application's source code to detect syntax errors, bugs, and vulnerabilities, providing vital feedback to developers.

The static nature of SAST scans means the tool doesn't need to run your source code. It merely inspects the code within your files, ensuring tests are kept performant and portable. For this reason, SAST is often one of the first stages of testing in the development pipeline—discovering a security problem can cause the rest of the pipeline to be terminated early, preventing potentially vulnerable code from being called by later dynamic tests.

Adding SAST to your SDLC workflows allows you to spot and remove issues before they're included in production software. However, with a wide variety of SAST solutions available, it can be challenging to select the right one. In this article, we'll explain how to evaluate different options to select the best one for your project and team.

Why is SAST important?

SAST scans provide developers with insights into the quality and security of code during the development process. SAST is used to enforce coding standards, prevent bugs that could cause unexpected runtime behavior, and identify potential misconfigurations and security risks.

Utilizing a SAST solution within your SDLC is one way to identify new code risks as they enter your project. Tools can surface problems before they are compiled into a finished binary or distributed to customers. Because code isn't executed by the scanning engine, SAST allows teams to identify threats that could compromise CI/CD or test servers, ensuring mitigation takes place before they can affect future pipeline stages.

Furthermore, SAST can help you achieve and maintain compliance with applicable regulatory standards such as ISO requirements, SOC2, HIPAA, and PCI DSS. Although SAST scans don’t produce an exhaustive picture of the risks facing your project—other security mechanisms, such as dynamic tests and supply chain hardening, are also required—you can use them to demonstrate the absence of certain coding issues that could affect a compliance audit's outcome.

How to evaluate a SAST solution for your application security program

The SAST arena has expanded considerably over the past few years. It includes developer-oriented tools that work with specific languages, tools that are engineered for security and risk-management scenarios, and generic scanning engines that can be integrated with many different project types.

To successfully adopt SAST, you need an accurate solution that can be easily added to your development process. SAST should empower developers with new and actionable information, instead of creating friction that leaves engineers waiting for results.

Here's how you can evaluate different SAST tools and providers so you can make the right choice first time.

Ease of static scanner deployment and maintenance

SAST scans should be easy to deploy and integrate with your project. Tools that require complex configuration result in additional overheads and will require specialist knowledge to maintain over time.

Many solutions require you to manually configure new CI/CD pipeline stages before you can run scans and access their results. This increases set up time and can cause missing code coverage if administrators don't enable SAST for their projects.

Tools that support pipelineless execution offer a lower effort experience with automatic coverage for new repositories. They can simultaneously minimize the burden on administrators while delivering faster, more accurate results.

Code coverage support

It goes without saying that whichever SAST solution you choose, it needs to support the languages and frameworks that you're using in your product. Some SAST tools only work with specific languages whereas others such as Semgrep use customizable rules to support many different languages.

If your stack depends on multiple languages or frameworks, you should consider one of these general-purpose tools to support standardization within your teams. This is also helpful when you need to work with legacy code that lacks dedicated language coverage from a purpose-built tool.

To ensure that all risks are discovered, you need to attain 100% coverage of all the code assets in your repositories. Tools capable of supporting every language that's used can therefore simplify report output and reduce overall pipeline execution time. It's also useful to look for tools that can list the files that were skipped due to exclusion rules or missing language coverage.

Security scanning performance

SAST is most effective when it's fast: scans should occur in real-time, as code is authored. Shifting SAST as far left in the development process as possible allows new errors and risks to be discovered before they have a chance to persist in your project.

Analyze the available tools to understand your options for accessing and distributing scan results. Results should be immediately made available to the individuals who need them—such as the developer who pushed a commit, or the security team that initiated a scheduled scan—so the SDLC feedback loop is kept tight and efficient. Any roadblocks in the way of developers will reduce productivity and discourage ongoing use of the SAST solution.

Beware that different scanning tools may impose requirements on the kinds of input they work with. Some solutions scan source files, whereas others analyze the output of compilation processes. This affects overall scan performance; tools that use compiled inputs will extend your pipeline's run time because compilation will have to occur before the scan can start.

Discovery, prioritization, and mitigation of SAST risks

Any SAST scanner you select should be focused on uncovering new findings that can be actioned to effect a quality or security improvement in your project. Scanners which don't help you prioritize and mitigate risks can lead to alert fatigue scenarios, where issues accumulate in your backlog because it's unclear which ones are actually relevant.

Look for cohesive SAST solutions that not only find issues, but which also explain why the problem has occurred and suggest an initial prioritization. This information should be provided directly within the SAST tool so that developers don't have to repeatedly cross multiple applications.

Users should be able to interact with SAST alerts and reports, such as by following links to view affected code in the repository, or apply a suggested mitigation. Tools that can't provide mitigations require developers to have pre-existing knowledge of the issue, why it presents a risk, and how it can be resolved. In cases where the developer is unfamiliar with the code, perhaps because they weren't the original author, this can impede the resolution process and lead to incorrect severity and priority assessments.

Presentation of SAST risk context

Similarly, SAST scans need to provide accurate risk context information so that developers, security leads, and project managers can efficiently determine the extent to which the product or organization is impacted. Alerts should include information such as the project the issue was found in, whether the scan ran against a production or development build, and the business importance of the repository. Other characteristics, such as the individual who introduced the issue and the developers best suited to resolving it, are also useful to expedite the resolution process.

These details help you efficiently triage issues and prioritize your backlog. Minor code quality issues within projects created for internal use are unlikely to require an immediate fix, for example, whereas vulnerabilities detected in your core product's repositories should be elevated to the top of the queue.

Custom SAST rules

SAST isn't a "one-size fits all" category. Although you can get good results out-of-the-box, for long-term use you should seek customizable solutions like Semgrep that allow you to extend the scanning engine with your own rules and policies. This permits use of one SAST tool across your entire product catalog.

Being able to customize behavior on a per-project, per-repository, or per-team basis ensures different scenarios aren't unnecessarily encumbered by requirements held by the others. You can maintain a central ruleset that all code should adhere to, then layer in the specific customizations that apply to individual situations.

Visibility into security operations

To support security teams and administrators in their work, SAST solutions should ideally provide enough information about their own usage to facilitate full visibility and oversight. Audit logs and usage analytics allow you to understand which teams and developers are effectively using scans, versus those which may need additional support to adopt SAST and start responding to risks.

These insights can reveal trends in the types of issues that are being discovered too. Recurring vulnerabilities, or repeated incidences of similar code quality problems, can indicate that teams need additional training so they can recognize and prevent those risks.

Scan frequency and automation

SAST scans should be automated, frequent, and comprehensive to provide maximum protection and ensure consistency throughout your entire SDLC.

A pipelineless approach provides advantages in this area, allowing you to easily set up scheduled scans that occur independently of code events such as merges and pushes. This provides continual coverage as SAST rules and vulnerability definitions change, even for projects that aren't regularly maintained. Only running scans as part of a pipeline could mean zero-day vulnerabilities go undetected until you next commit to your project.

As we've discussed above, the results of scans—whether triggered manually, on a schedule, or within a deployment pipeline—should be automatically distributed to relevant team members, ready for actions to be applied. Tools that can send automated alerts to IDEs, chat apps, or pull requests guarantee information is presented where devs will see it, with easy access to available mitigations.

Summary

SAST scans analyze code without running it to find bugs, misconfigurations, and vulnerabilities. This provides rapid feedback to developers, allowing issues to be fixed before they cause a problem in later testing stages or after deployment to users.

When choosing a SAST solution, you should balance factors such as scan performance, code coverage, customization, and the extent to which each tool helps you find, prioritize, and fix issues. SAST scans ideally supply actionable information that allows you to gauge the severity of each risk and understand how it can be resolved. This empowers you to improve application security and quality by ensuring relevant problems are dealt with before code gets deployed.

Try Arnica’s SAST scanning today for free!

What Developers Can Learn from Taylor Swift's Re-recording Strategy

arnica-simon — Tue, 13 Jun 2023 16:48:22 +0000

By Nicholas Rodine

TLDR:

Drawing inspiration from Swift's strategic decision, developers too can seize control and ownership of their codebases, essentially safeguarding their 'masterpieces' from potential exploitation.

“In an era where digital assets and intellectual property have become the lifeblood of industries, the need for control and ownership has never been more critical.” With this mantra in mind, let's venture on a journey through code security, bearing an unlikely resemblance to a Grammy-winning artist's fight for ownership over her music.

Long Live: A Tale of Music and Code

Taylor Swift, the country girl turned pop phenomenon, known as much for her intricate lyrics as her litany of ex-lovers and the songs that were written in their aftermath, did something groundbreaking in the music industry. Her bold move? Re-recording her early albums. Now, you may be wondering, what does T-Swift's melodious journey have to do with software development? Well, dear reader, like the narratives woven into her songs, there's a compelling story here that every developer should tune into.

Taylor, the blonde-haired, guitar-strumming darling of Nashville, found herself embroiled in a high-stakes dispute with her former label, which held the rights to her original recordings. Her solution was as innovative as it was defiant – re-record the old tracks, creating new assets she owned entirely. As we pluck the strings of this narrative, parallels emerge, resonating with the everyday struggles faced by software developers navigating the complex world of code ownership and security.

The Story of Us: Welcome to the Development Room

Let's move from the glitz of the music industry to the world of software development, where codebases are the equivalent of a musician's discography. They are intricate compositions, echoing the intellectual prowess and the tireless effort of dedicated individuals and teams. And just like Swift's masterpieces, these codebases can be vulnerable to exploitation if not adequately secured.

Take for instance our fictitious yet relatable protagonist, a software developer named James. James is a dedicated professional, fond of obscure band tees, artisanal coffee, and an occasional binge of Game of Thrones. It's late on a Friday. He's ready to finish his work and dive into the latest expansion of his beloved Zelda franchise, Tears of the Kingdom.

He reviews his files, commits, and pushes his code. A sense of accomplishment washes over him as all tests pass. He dreams of epic battles and legendary loot waiting for him in the mysterious depths of the underdark.

I Knew You Were Trouble: The Perilous Depths of Git History

But come Monday, trouble was waiting. His coworker, Betty, a sharp-eyed QA engineer with an uncanny affinity for finding bugs and a soft spot for Taylor Swift's breakup songs, notices something alarming. James had unwittingly pushed his AWS key to the dev environment. Hidden in the depths of a test, commented out and hardcoded, it was like a secret message hidden in a Swift lyric, but far less romantic.

James, like any Swiftie hearing "we are never ever getting back together" for the first time, is in denial. "No problem," he thinks. He deletes the comment, pushes the change, and believes the trouble has passed.

However, as any seasoned Swift fan or developer knows, trouble doesn't fade away so quickly. The secret is still lurking there, in the annals of Git history. Even if he cherry-picks it out and force pushes, he's faced with the dread of convincing everyone to rebase onto his new branch - an ordeal about as popular as wading through a sea of digital glitches on a certain infamous ticket site, all in a desperate race to snag tickets for Swift's latest concert.

Everything Has Changed: A New Era of Secure Coding with Arnica

But what if there was a way to 'Shake It Off', much like our queen of pop does with her haters? This is where the power of Arnica comes into play, turning a Blank Space into an opportunity.

Arnica, like a knight in shining armor, can rewrite your Git history, in real-time, effectively 're-recording' your codebase to censor sensitive information like passwords. It's as if you had a team of skilled songwriters (and cybersecurity experts) helping you tweak your masterpiece until it's ready for the spotlight.

Now, let's revisit that fateful Friday, but this time, we're venturing into a parallel universe where Arnica is James' ally:

It's Friday evening. James, his veins pulsating with the potent rush of Monster Energy and a burning determination to vanquish Ganondorf, is about to commit his code. His fingers fluently string together a git push, an action they have performed countless times before. Even before the push command fully processes, James is already nestled on his couch, gaming controller in hand, ready to dive back into his virtual adventure.

As James' code begins its journey, Arnica's servers spring into action. They're as alert and keyed-in as Swifties on a mission, deciphering Taylor's cryptic Instagram clues for hints about her next album drop. In this rapid-fire scenario, Arnica swiftly identifies the oversight. With the elegance of a seasoned conductor directing a symphony, it rectifies the issue—all this happening even before any of James' team members can utter, "Look What You Made Me Do."

With Arnica, the perilous story turns into a 'Love Story'. James' codebase is now secure, and he holds the power and control over his digital assets, much like Taylor with her freshly re-recorded albums.

Wildest Dreams: A Better Coding Future

In our increasingly digital world, the parallels between Taylor Swift's strategic re-recording decision and maintaining a secure, reliable codebase are unmistakable. In essence, both are about reclaiming and preserving the integrity, quality, and history of your work.

So, code wizards, digital developers, and miracle makers: as we gaze into the horizon of a secure coding future, let's look to Swift's resourcefulness and resilience for inspiration. As she had to navigate the tumultuous terrain of the music industry, we too must overcome challenges to ensure our codebases are robust and safe.

Just remember, with Arnica by your side, you're never Out Of The Woods. You're Ready For It, set to embark on an adventure of coding where every commit, push, and pull request is a Fearless step towards better, safer coding practices. Never let any security violation tell you it's going to stay, stay, stay. You can shake it off, and in the process, create your own masterpiece of clean, secure, and reliable code.

So, to every James, Betty, and developer who has ever faced a daunting bug or a risky commit, remember this: "We're coding in a getaway car, left our old bugs in the dust - no, they won't catch us, developers gonna code, code, code." As Swift's lyricism guides us in our musical journey, may it also inspire us in our coding endeavors. Remember, just like in our favorite pop songs, even in code, the essence is in the narrative, the emotion, and the will to tell our story. Just keep coding.

How We Converted a GitHub Tool Into a General Purpose Webhook Proxy to Supercharge Our Integration Development

arnica-simon — Fri, 21 Apr 2023 17:11:46 +0000

Doron Guttman and Roei Ben-Harush @ [arnica], April 2023

TL;DR

Webhooks automate workflows by sending data from one app to another on certain events. They require a public URL, which can be a problem for testing or development. Smee.io is a payload delivery service which proxies payloads from the webhook source and transmit them to a locally running app. However, it was designed for GitHub, so customizing it for other services is necessary - here's how we did it.

WIIFM (what's in it for me)

Learn what is a webhook
Learn what is smee.io and how it can be used with webhooks
Learn how to customize smee.io for your own needs
Learn about some alternatives

Introduction

Webhooks are a powerful way to automate workflows and integrate different applications. They allow you to send data from one service to another when certain events happen. For example, you can use webhooks to notify your team on Slack when someone pushes code to GitHub, or when a new issue is created. Slack also uses webhooks to let your application know a user has interacted with a card you sent them on Slack.

However, webhooks have a limitation: they require a public URL that can receive HTTP requests from the webhook source. This means that a webhook cannot be configured to send a message to an endpoint it can't reach, like http://localhost; if you want to test or develop your webhook integration locally, you need some way to expose your local host to the internet.

This is where smee.io comes in handy. Smee.io is a webhook payload delivery service that uses Server-Sent Events (SSE) to proxy payloads from the webhook source, then transmit them to your locally running application. Smee.io is "Made with ♥️ by the Probot team." (and we thank them for it 🙏). It's free, easy to use, and works with any service that supports webhooks - or at lease, in theory it should.

Since smee.io was designed to work with Probot for enabling development of GitHub applications it works very well with GitHub webhooks and its UI is somewhat tailored for use with GitHub (parsing GitHub specific headers); however, if you want to leverage smee.io for other services that use webhooks you may hit a few snags.

Specifically when developing our Slack app, we ran into some of those snags.

In this blog post, I will show how I customized smee.io so we can use it to integrate with Slack webhooks. This should be applicable for other webhook services.

So what are the issues with Smee.io?

While smee.io provides a lot of benefits while developing and testing your webhook integrations, especially with GitHub, it does have some downfalls. Some of which proved to be a real blocker for us.

Downtime

First of all, since smee.io is a free service (thank you again!) it is completely understood why it would have some limitations. One of which is that there is no guarantee to it's availability. Unfortunately I could not find a service which monitors smee.io so I can provide factual information on how often it is down, but I can tell you that as a team working mostly in US Eastern time zone, we encounter it a lot.

Reservation

In order to create a channel on smee.io, you should point your browser to https://smee.io/new, which will then redirect you to a randomly created channel. That random channel ID would be up to 16 alphanumeric characters. From the smee.io code:

app.get('/new', (req, res) => {
  const protocol = req.headers['x-forwarded-proto'] || req.protocol
  const host = req.headers['x-forwarded-host'] || req.get('host')
  const channel = crypto
    .randomBytes(12)
    .toString('base64')
    .replace(/[+/=]+/g, '')

  res.redirect(307, `${protocol}://${host}/${channel}`)
})

Since that channel ID is not saved anywhere, together with the fact the channel endpoints (app.get('/:channel'...) and app.post('/:channel'...)) don't care about the channel name itself, means you can actually pick your own (e.g. https://smee.io/foo). However, if anyone knows your channel ID, they will be able to listen to messages sent to the channel, so you don't want to pick an easily guessable channel ID.

Security

Smee.io relies on message authentication rather than channel security. This makes a lot of sense as smee.io has no configuration and all the webhook messages GitHub sends out have a signature header (e.g. X-Hub-Signature-256: sha256=xxxxxxx...). This is actually a good practice, which Slack follows as well (different header), however, not all services do. It would have been great if you could protect your channel with a key somehow, wouldn't it? Without it, someone can spam or listen to our channel, intentionally or not. It would also mean that you would give your channels meaningful names, like /slack-integration or /github-app

Content Type

Smee.io only supports application/json content as the webhook payload. I do not think that was intentional, but it was not intentionally designed to support other content types as well. This is due to the use of a common Express.js body parsers:

app.use(express.json())
app.use(express.urlencoded())

Taking Slack webhooks as an example, most events are sent as application/json, however, some others like the interaction events, are sent as URL encoded (application/x-www-form-urlencoded). I, personally, don't understand why Slack chose to do so, but it is what it is.

Because smee.io uses the express.urlencoded body parse, when the it receives content-type: application/x-www-form-urlencoded it will automatically convert the payload (e.g. key1=Some%20Value&key2=Other%20Value) to JSON:

JSON.stringify(req.body) // -> '{"key1":"Some Value","key2":"Other Value"}'

This is very useful when you want to work with the content, which smee.io does in order to display the content on the web UI, but it is breaking the forwarding of the message to the clients (as the client expects it to arrive as URL encoded payload)

Endpoint Verification

Smee.io is a payload delivery service (PubSub) which receives payloads and forwards them to all subscribers:

This means it automatically responds to the service with 200 OK, this happens even if there are no subscribers:

app.post('/:channel', async (req, res, next) => {
  await bus.emitEvent({ ... })
  res.status(200).end()
})

Unfortunately, with Slack, there's an ownership verification phase, in which you have to respond with a challenge. With a payload delivery service, like Smee.io, there is no way to verify the endpoint, which means you can't use it for Slack webhooks. Note this verification only happens once, when you configure the service.

Path Forwarding

Smee.io does not support path forwarding. For example, if your webhooks service includes some of the important information in the path (e.g. https://smee.io/foo/:type, where :type is the type of payload/event), it would not work with smee.io as it is not subscribing to the rest of the path which follows the /:channel. The service will actually receive a 404 Cannot POST /foo/:type.

Alternative Solutions

Public IP / Port Forwarding

Public IPs can be costly and hard to manage. In addition, it require a different configuration (and sometimes entire new application instance) for each developer. Your app has to be deployed out in the public as you'll need a public connection to your dev box. You can combine a public IP solution with port forwarding and trade off some of the complexity, but you will probably have to ask your IT for help with this every time there's a change.

Tunneling Service

Tunneling services can be considered as a solution in some cases. Services like ngrok, frp, localtunnel and sish create a public endpoint that tunnels communication to your local endpoint via a tunnel client.

This is great when you need to craft a special response to the webhook service, for example the Slack ownership verification mentioned above. In addition, tunneling solutions support path forwarding out of the box as it tunnels the full request.

Tunneling services have downsides too. For example, it is a 1:1 relationship between a tunnel endpoint and a local app (there can be only one local app listening to a public endpoint). When using HTTP webhooks, for every webhook message (request) there must be a response.

In our case, we have multiple developers working on the integration at the same time; this means that at any given time, while using ngrok we had to edit the webhook configuration and switch it over from one developer to the other, thus "stealing" the connection.

Comparison

Let's compare the different solutions discussed above:

Alternative	Description	One-to-One ¹	One-to-Many	Security	Location	Cost	Path Forwarding	Comments
Public IP	Webhooks will call your public IP	✔️	❌	Up to you	Static²	$$$	✔️	Usually public IPs are not free and are complex to manage for each developer. App has to be deployed out in the public and you need a public connection to your dev box.
Port forwarding	Webhooks will call your public IP:PORT	✔️	❌	Up to you	Static²	$	✔️	You will probably have to ask your IT for help with this every time there's a chance.
Tunneling service	Webhooks will call your assigned tunneling endpoint	✔️	❌	Built-in	Everywhere	$	✔️	Usually there's a cost associated with keeping a fixed tunneling endpoint.
Free Delivery Service	Like smee.io	❌	✔️	Guess channel name	Everywhere	0	❌	No special cases. Downtime.
Self-hosted Delivery Service	You can host your own smee.io	❌	✔️	Customized	Everywhere	0-$	Customized	You can customize the code for your needs. You can deploy for free in some cases (e.g. Vercel or free-tier cloud providers) or at low cost (e.g. ECS)

¹ One-to-one solution meaning you need to configure it for each developer.
² If you want to work from another location it won't work (without additional services, like VPN).

Customize Smee.io

Given the above, we decided to take Smee.io and customize it to our needs.

Starting Point

My recommended starting point is to fork/clone the smee.io repo and get it working. And by working, I don't mean deploying it, but being able to build and run it locally to a point where you can place a break point in the code and have it pause there. This is necessary in order to customize any code. I actually had some issues doing that with the main branch as it was in commit 3a01759.

I'm using WSL2 and I'm not sure it was related, but I had to replace node-sass@4.14.0 with sass@1.58.3

-    "node-sass": "^4.14.0",
+    "sass": "^1.58.3",

and upgrade a bunch of packages:

-    "babel-loader": "^8.1.0",
+    "babel-loader": "^9.1.2",

-    "mini-css-extract-plugin": "^0.9.0",
+    "mini-css-extract-plugin": "^2.7.2",

-    "node-sass": "^4.14.0",
+    "sass": "^1.58.3",

-    "webpack": "^4.43.0",
+    "webpack": "^5.75.0",
-    "webpack-cli": "^3.3.11"
+    "webpack-cli": "^5.0.1"

I also had to add the --inspect flag to the start-dev npm script

-    "start-dev": "concurrently \"nodemon --ignore src/ ./index.js\" \"webpack -w --mode development\"",
+    "start-dev": "concurrently \"nodemon --inspect --ignore src/ ./index.js\" \"webpack -w --mode development\"",

and declare a newer version of the node engine compatibility in package.json

   "engines": {
-    "node": "12.x.x"
+    "node": "16.x.x"
   },

as well as in the Dockerfile together with specifying the platform architecture for compatibility building on MacBooks as well

-FROM node:12-alpine as bundles
+FROM --platform=linux/amd64 node:16-alpine as bundles

You can find the final package.json and Dockerfile here.

Do the Work

Now that I had a working local dev environment and was able to successfully build and run the docker image, I was ready to customize the application.

Support Configuration

This will allow to set a security operation mode and configure the channels. I chose to use the config package as I had good experience with it and it supports cascading config options.

Create the default base configuration:

// config/default.js
/**
 * Mode enum
 * @enum {string}
 */
const Mode = {
  /** block all */
  block: 'block',

  /** no protection */
  open: 'open',

  /** only in list */
  allowed: 'allowed',

  /** requires password */
  password: 'password'
}

module.exports = {
  channels: {
    /**
     * Mode
     * @param mode {Mode} one of the modes
     */
    mode: Mode.allowed,
    list: {
      protected: {
        password: 'password'
      },
      open: {
        password: null
      },
      slack: {
        password: 'slack',
        handler: 'slack'
      }
    }
  }
}

Later, during deployment I can mount a config/local.js file to my docker and it will override some items in the config/default.js file.

You'll note that the slack channel configuration defines a handler: 'slack', you'll see where that comes to play in a bit.

Add Support for URL Encoded Payloads

When a URL encoded payload is received, I want to pass it as is to the subscribers. For that, we need to keep the raw content (it will be signed as well in most cases), so I piggybacked on the body parser verifier:

app.use(express.urlencoded({
  extended: true,
  verify (req, res, buf, encoding) {
    if (buf?.length) {
      req.rawBody = buf.toString(encoding || 'utf8')
    }
  }
}))

This saves the original buffer into a new rawBody property based on this wonderful gist (thanks stigok! 🙏). Then we need to forward the raw body to the subscribers:

await bus.emitEvent({
  channel: req.params.channel,
  payload: {
    ...req.headers,
    // forward raw body if captured (application/x-www-form-urlencoded)
    // otherwise, forward the parsed body
    body: req.rawBody ?? req.body,
    query: req.query,
    timestamp: Date.now()
  }
})

Create Custom Middleware

I wanted to touch the original code as little as possible, so it would be easy to merge updates from the upstream repo. This means there should be a minimal footprint for the custom handlers and security and the changes should be encapsulated as much as possible. The best way to do that in the Express.js world is via middleware.

First thing first, load the configuration and create a custom middleware installer:

// custom-middleware.js
const config = require('config').util.toObject()
const mode = config.channels?.mode || 'block'

module.exports = function customMiddlewareInstaller(app) { }

The middleware will first take care of the /new route and block it if not in open mode:

module.exports = function customMiddlewareInstaller(app) {
  app.get('/new', (req, res, next) => {
    if (mode !== "open") return forbidden(res)
    // let the next layer handle the request
    return next()
  })
}

Next we need to handle the /:channel routes:

module.exports = function customMiddlewareInstaller(app) {
  app.get('/new', (req, res, next) => { ... })
  app.use('/:channel', async (req, res, next) => { }
}

To simplify the password protection we can embed it in the channel name (e.g. http://mysmee.io/foo:password). That way we will be able to support all (I hope) webhook services. Even those who do not support custom headers or query params. To resolve the password³:

module.exports = function customMiddlewareInstaller(app) {
  ...
  app.use('/:channel', async (req, res, next) => {
    const channel = req.params.channel;
    const [name, password] = channel?.split(':') || []; // Note: password cannot contain the `:` character
  }
}

³ Do note that I'm using clear-text password in both sender (URL) and configuration for the sake of simplicity. This solution is not meant to be used in production. You can extend this code to support a more robust and secure solution, but that is outside of the scope of this post

Resolve the channel options from configuration:

module.exports = function customMiddlewareInstaller(app) {
  ...
  app.use('/:channel', async (req, res, next) => {
    ...
    const options = config.channels?.list?.[name];
  }
}

Resolve custom handler from channel options:

module.exports = function customMiddlewareInstaller(app) {
  ...
  app.use('/:channel', async (req, res, next) => {
    ...
    const handler = req.method === 'POST' && options?.handler
          ? require(`./handlers/${options.handler}`)?.bind(null, req, res, next)
          : null;
  }
}

What this means is that is a handler is configured, the code will try to load it from the /handlers folder. e.g. for the configuration shown above the slack channel had the handler: 'slack' configured, which means that the code will try to resolve the module from ./handlers/slack; if it finds it, it will bind the connection params to the default export method and later execute it if it passes all the conditions.

Note that with node, loaded modules are cached, so it actually only loads it once while the application is running.

Moving on... based on the configured mode, apply conditions:

module.exports = function customMiddlewareInstaller(app) {
  ...
  switch (mode) {
    // block everything
    case 'block': return forbidden(res)

    // allow everything 
    case 'open': break;

    // allow only if in list
    case 'allowed': {
      if (options?.password && options.password !== password) return forbidden(res)
      break;
    }

    // allow only if in list and password protected
    case 'password': {
      if (!options?.password || options.password !== password) return forbidden(res)
      break;
    }

    // misconfiguration
    default: throw new Error(`Invalid mode ${mode}`)
  }

  // if there's no handler OR it return 'false'
  // request should be handled by the next layer
  if (!await handler?.(req, res, next)) return next()
}

And here's the special Slack handler:

// handlers/slack.js
module.exports = function slackHandler (req, res) {
  const challenge = req.body?.challenge
  console.log(`slackHandler[${challenge || 'passthrough'}]`)
  if (!challenge) return false
  res.send(challenge)
  return true
}

With this custom handler, our flow would look like this:

Put it all together with error handling:

// custom-middleware.js
const config = require('config').util.toObject();
const mode = config.channels?.mode || 'block'

function forbidden(res) {
  return res.status(403).send('Forbidden')
}

function internalServerError(res) {
  return res.status(500).send('Internal Server Error')
}

module.exports = function customMiddlewareInstaller(app) {
  app.get('/new', (req, res, next) => {
    try {
      if (mode !== "open") return forbidden(res)
      // let the next layer handle the request
      return next()
    } catch (e) {
      console.error('customMiddleware', e)
      return internalServerError(res)
    }
  })
  app.use('/:channel', async (req, res, next) => {
    try {
      const channel = req.params.channel;
      const [name, password] = channel?.split(':') || [];
      const options = config.channels?.list?.[name];
      const handler = req.method === 'POST' && options?.handler
          ? require(`./handlers/${options.handler}`)?.bind(null, req, res, next)
          : null;

      switch (mode) {
        // block everything
        case 'block': return forbidden(res)

        // allow everything 
        case 'open': break;

        // allow only if in list
        case 'allowed': {
          if (options?.password && options.password !== password) return forbidden(res)
          break;
        }

        // allow only if in list and password protected
        case 'password': {
          if (!options?.password || options.password !== password) return forbidden(res)
          break;
        }

        // misconfiguration
        default: throw new Error(`Invalid mode ${mode}`)
      }

      // if there's no handler OR it return 'false'
      // request should be handled by the next layer
      if (!await handler?.(req, res, next)) return next()
    } catch (e) {
      console.error('customMiddleware', e);
      return internalServerError(res)
    }
  })
}

Install the Middleware

In the server.js file, we'll import the middleware:

const customMiddlewareInstaller = require('./custom-middleware')

and use it as the last middleware before the endpoint registrations:

...
app.use('/public', express.static(pubFolder))
customMiddlewareInstaller(app)

app.get('/', (req, res) => {
...

Path Forwarding?

Well, that will require a change in the smee-client as well. So maybe a follow-up?

Deployment

We decided to deploy on our AWS ECS. For simplification we created a deploy.sh script, you're welcome to use it as well, though it is outside the scope of this post.

References

What to consider before enforcing MFA on GitHub

arnica-simon — Wed, 19 Oct 2022 21:02:02 +0000

Multi-factor authorization (MFA) is becoming an industry standard for software supply chain security in an era of data leaks, compromised hardcoded secrets, and an endless number of malicious actors operating 24/7. Developers and their ecosystem are increasingly a target, as the meaning of changing source code becomes equivalent to accessing cloud environments, especially where everything is deployed as code.
The fact that these breaches can lead to large-scale damage to an organization makes securing the company’s software supply chain critical. This article explores what an organization should consider when deciding whether to enforce MFA, as well as when and how the different stages of Security Assertion Markup Language (SAML) identity management can factor into the decision. We also discuss the limitations of MFA and how Arnica can help transition an organization smoothly to enforcing GitHub MFA to comply with software supply chain best practices.

Background: GitHub’s identity management

GitHub provides several different ways for users to authenticate and gain access to a GitHub organization’s private resources. Developers can create and manage their own accounts, either logging in using GitHub.com directly or via an additional security layer using SAML SSO. Alternatively, organizations using GitHub Enterprise Cloud can choose to leverage Enterprise Managed User accounts, which are completely separate from any personal GitHub account a developer may have; these also allow the organization to have full control over account provisioning, access, and privileges.

Enterprise Managed User accounts give organizations the most control over the activities of the account holders, with the ability to audit account activity, limit the scope of contributions and social activity to private repositories, and define specifications for user profiles and usernames. However, this option may not be the most developer-friendly, and tradeoffs have to be made between the developer experience and levels of code security.

By opting to allow developers to use their own accounts to sign in, with or without SAML SSO, developers are able to stay in control of their own GitHub identity. They also don’t have to manage a separate “work” GitHub account and can keep data such as commit statistics all in one place. To see it in action, go to https://github.com/settings/profile and enable the checkbox as seen in the screenshot below:

More information about viewing contributions on your GitHub profile can be found here: https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/viewing-contributions-on-your-profile

Benefits of enforcing MFA

It is widely known that unauthorized access via compromised developer accounts is a source of risk for the software supply chain. To mitigate this risk, MFA has long been recommended as an effective defense to augment traditional password-based authentication and third-party authentication or “Bring Your Own Identity” (BYOI). For example, in the CIS Software Supply Chain Guide, a set of software supply chain best practices that can help organizations reach CIS compliance, the Source Code controls section highlights the importance of restricting codebase access to only authorized individuals. This includes mandating MFA for all code contributors when authenticating. GitHub also announced that it is requiring all users to enable 2FA by the end of 2023. Woot woot!

Avoiding disruption when requiring MFA

When enforcing MFA, it’s important to ensure that all members of the organization are aware of the requirement ahead of time. For example, when GitHub MFA is enforced for a GitHub organization, any members who do not comply will be removed from the organization. GitHub provides a way for administrators to see which members are removed as well as steps to restore membership, but this could confuse developers and disrupt existing workflows if it is not properly communicated.

Many organizations also create users that are being implemented as service accounts, such as bots or processes that use GitHub APIs periodically. GitHub offers a way to enforce MFA for these accounts as well while still enabling programmatic access via personal access tokens (PATs). Organizations enabling SAML SSO will need to instruct the service account owners to authorize PATs in order to access the protected organizations. It is worth keeping in mind that GitHub automatically expires tokens that haven’t been used in over a year, so if there is an annual script, it needs to be taken into consideration. If configured as explained, there should be no issues with continuing to use these accounts after enforcing GitHub MFA.

MFA and SAML SSO

If your GitHub organization is not using SAML SSO for authentication and allows personal account access, requiring MFA for personal accounts is a good first step to reducing the risk of unauthorized access:

If your organization is transitioning from allowing personal account access to SAML SSO, GitHub allows two levels of SAML integration: enabling SAML without enforcement and enforcing SAML.

When SAML is enabled

Enabling SAML without enforcement is a good intermediate step to full enforcement. While developers are being onboarded to SAML SSO, there will be a mix of users accessing private resources who are authenticating through personal accounts and SAML SSO. Effectively, during this period, the same vulnerabilities exist as when there is no SAML integration. As you are rolling out SAML SSO registration, if your identity provider does not already require MFA, it would be good to communicate and roll out enforcement of GitHub MFA at this time to ensure everyone is in full compliance in one step.

When SAML is enforced

When SAML is enforced, your personal GitHub identity is linked with your identity provider’s SAML policy, and any unauthorized accounts will have access revoked. Many identity providers require MFA when initializing a SAML session, and with enforced SSO, your GitHub organization can benefit from that security along with all other accounts linked to SAML SSO. If no MFA is configured with the identity provider, then enforcing GitHub MFA can provide security for your GitHub resources. However, you may have to deal with the increased management burden of decentralized MFA enforcement for each service application your developers use.

Limitations of MFA

While MFA may increase protection against software supply chain attacks, it doesn’t completely prevent unauthorized access. Token-based or SSH/GPG key-based authentication can still be compromised, just like passwords. While you can further harden SSH and GPG key-based authentication with a local password, the developer experience of this workflow is not ideal since it requires an extra step when pushing code.
Non-bot interactive service accounts, such as an automation service account that simulates user behavior, may encounter problems authenticating when MFA is enabled. There are some workarounds for this, such as requiring human intervention to authorize a service account when needed, but this is a manual step. Another option is to lower the MFA requirement while keeping other security filters such as an IP address allowlist, but there are enough challenges with this route to warrant a completely separate post.

Arnica can help transition to MFA and SAML SSO

As mentioned earlier in this article, the transition to SAML SSO must be done with care since GitHub will remove any account that is not already registered in your identity provider. One method to make this transition smoother is to ensure the count of GitHub identities is equal to the count of mapped SAML identities:

This will give you a way to verify that everyone bringing their own identity is also enrolled in SAML SSO so that enforcement can be turned on with minimal disruption. At the same time, it helps keep your codebase safe from unauthorized access before SAML SSO is properly enforced; it also follows the security principle of least privilege to source code.
One common use case: In a Bring-Your-Own-Identity paradigm that does not have properly enforced SAML SSO, an employee who departs the company may still have access to your resources if permissions are not managed correctly. Arnica maps Bring-Your-Own-Identities to SAML identities, which is part of the free plan. Here is an example of such mapping:

With Arnica’s access management capabilities, you can find out who has permissions and perform user entitlement reviews easily.