Originally published by Dazz.

Introduction

Ready to tackle a challenging topic for DevSecOps and security teams in the application security space? Ready or not—let’s talk about increasing and governing the adoption of scanners.

The Application Security Process

Application security is a labyrinth with myriad stages and steps as applications are developed internally. Within development processes, there are multiple points to place hooks and gates—it’s a matter of determining where to put them to get proper visibility into testing for security flaws and then governing it all in a single pane of glass.

We’re all probably using some sort of source code management tool—a GitHub, a GitLab, Azure DevOps, what have you. Since the code is stored there, that’s the first place to start hooking scanning tools for software composition analysis and static security testing. It’s a common practice to use these tools to scan your code base and find flaws, defects, and non-compliant code.

After the code is written, the next step is to build it into artifacts—binaries that you can run in your workloads. In the build process, several tools will help you scan as well. Whether you're using modern DevOps CI/CD pipelines or less mature ones, you can scan infrastructures, code deployments, and more.

Once the code is built into binaries or artifacts, the next stage is moving to a lower environment to perform penetration testing. This might include pre-production pen testing of the application, searching the binaries for secrets, or deploying the application into a lower environment for web app scanning. This provides a comprehensive way to assess the application and all potential risks.

Finally, the application is deployed. Once it’s deployed in the production environment, a new set of security tools is needed to scan within that environment.

Setting Hooks: Best Practices

Let’s dive deeper into the challenges at each step in governing scanner adoption, starting with the first hook that most application security teams would start with: the code.

Code Scanners

When we scan our application code, we can look for a few different things:

• Security flaws in our developers' code ( a SAST solution)
• Vulnerabilities in any open-source package that developers are delivering (a software composition analysis solution)
• Any issues or misconfigurations in the infrastructure defined by code (IaC scanning solution)
• Secrets accidentally committed into the code, which increases the risk of a breach

Types of Code Scanners and Their Pros and Cons

1. Code Cloners
   • Pros: Easier to achieve large coverage.
   • Cons: Misses some of the context in the actual process of compiling or deployment. No ability to block or be more proactive in pipelines themselves.
2. Scanner for Code Pushes
   • Pros: Scans new code immediately upon pull requests or merge requests.
3. Zip Scanners
   • Pros: Can scan the code in its entirety across multiple code repos
   • Cons: Tying back from zips to the code that created the problem can be cumbersome.

Choosing wisely among these methods is crucial. A mix of code scanner CLS and some pull request scanners can provide the best of both worlds.

Build Scanners

After scanning the code, the next step is the build. The code gets built into an artifact, binary, or container, and then there is an output to the code. In this stage, we see two primary methods for scanning:

1. Artifact Registry Scanners
   • Pros: Connects directly to the artifact registry, pulls the artifact, scans it, and analyzes it for risks such as open-source vulnerabilities.
   • Cons: Tying back from the artifact to the code that created it can be challenging.
2. Integrating into the Pipeline
   • Pros: Embedded in the pipeline right after the build, providing context of both the build and the code, and generating results of the risks in the compiled artifact.
   • Cons: Getting developers to adopt a scanner in each pipeline is a significant challenge

Post-Build Scanners

In test environments, you already have a running application, but it’s in a lower environment, so there's no risk of breaking or testing. This is where penetration testing and dynamic application security testing come into play.

1. Penetration Testing: Usually performed by contractors or internal pentesters, providing in-depth manual insights.
2. Dynamic Application Security Testing: Automated web app scanning for common issues, misconfigurations, and vulnerabilities.

Production Scanners

Even after releasing our applications, we can't sit back and relax. Vulnerabilities can be discovered post-release. New CVEs get disclosed, and we cannot assume that an application secure a year ago is still secure today. Therefore, we need constant runtime production scanners as a final validation process.

Looking for help?

Adopting scanners can be difficult due to the complexity around the various methods of deployment. As an application security practitioner or DevSecOps professional, it’s challenging to stay on top of every scanner and its deployment method. By unifying the context from different scanning stages, we can achieve a coherent risk picture for actionable insights.