Application Security Observability

AppSec works best when it is distributed across the engineering team. Bringing visibility to security bugs so all developers can share the fix responsibility.

Nobody wants to ship insecure applications. But with application security practices that lag behind frequent deployments (or are just non-existent), apps are shipped to production without ensuring that they are free of security bugs.

Bring application security visibility to your engineering team by surfacing results from your AppSec scans in Slack.

tl;dr

Security is shifting left and modern engineering teams are taking control over the security of their applications. Here are the best ways to get going:

• Scan Your Apps. Use both static and dynamic scanners to catch bugs in dependencies and in the code your team wrote.
• Use Modern Tooling. Use dev tools, not enterprise security platforms. Find tooling that integrates with your CI/CD tooling and other engineering team workflows.
• Create AppSec Visibility. Application security works best when distributed across the engineering team. Leverage Slack to surface your application scans to the whole dev team.
• Resist The Urge To Segregate. So often we want to lock down the information about Application Security bugs to only the Engineering team that owns the app. Make use of the whole talent pool and let people learn from mistakes.

Find Application Security Bugs

Engineering teams should be focused on preventing two types of security bugs: security bugs they added into the code and security bugs that are pulled in via dependencies. Both types of bugs are easy to introduce. Simple mistakes in the code your team writes can leave your app open to SQL injections, cross site scripting, and more. Or, you may have used a popular open source framework that has an exploitable vulnerability. Even the most seasoned developers will inadvertently introduce these bugs to their apps.

To find these bugs, you should use both types of application security testing:

• Dynamic Application Security Testing (DAST): This type of testing runs against a running version of your application, looking for security bugs that an external attacker would be able to find.
• Static Application Security Testing (SAST): This type of testing analyzes your code base to build a dependency tree and then compares the dependencies against a database of known vulnerabilities. Some options.

Historically, these types of security tests have been packaged together in complex enterprise security platforms that are built for security teams. As security shifts left, however, a new breed of tooling has been created that allows developers to take ownership over the security of their application. Obvious bias here, but we believe that StackHawk is the tool of choice for dynamic testing. For static testing, some modern options include Snyk, Dependabot, or SonarQube.

Automate! Don’t Let Bugs Hit Production

While learning secure development practices is always a good idea, automated checks for security bugs is the only scalable and consistent way to ensure that these bugs don’t hit production. If you don’t already have it, you should add Dynamic Application Security Testing (testing for bugs in the code you wrote) and Static Application Security Testing (testing for dependency vulnerabilities) into your build pipeline.

Upon merge, your build pipeline will spin up your application for a dynamic security test while at the same time checking for vulnerabilities in your dependencies. At first, many companies set these as non-blocking steps in their build pipeline prior to configuring blocking criteria.

Make Security Scalable with Visibility in Slack

Ensuring that your applications are secure can be hard at first. The traditional application security model is broken, with a reliance on stretched-thin security teams that can’t keep up with the speed of deployment. Responsibility for application security is shifting into the engineering team, and tooling and processes that work with the engineering team’s existing workflows is the only way that application security will become part of the engineering org.

One of the best ways to start on this journey is to push your pipeline application security checks into Slack. This brings visibility to the entire engineering team. When they see a scan with a new critical security bug, they can jump into StackHawk or a similar tool for details on the bug and how to fix it. In our experience, developers care about shipping quality code and will quickly address issues when they hit.

In StackHawk, developers can see the details of the bug, the request / response payloads, and links to documentation on recommended steps to fix. With this, bugs can be fixed quickly after they are introduced by any engineer on the team. While a developer is still in context of the code they just pushed, the cost of a fix is often quite small. With the Slack integration, your team can check for new bugs once a pipeline scan completes and quickly triage any bugs that are found.

To learn more about StackHawk + Slack, check out Slack in the App Directory or Slack announcement blog post.