Building AppSec Pipeline for Continuous Visibility

Most SaaS organizations need high-velocity engineering with multiple releases in a day where security & engineering teams are disproportionately scaled and no one likes to be blocked by other teams. So the AppSec industry is shifting left. This means the conventional security testing as a pre-release activity is not effective anymore in a fast-paced continuous environment. In this blog, we will explain our approach to building an application security pipeline for continuous security scanning using free and open-source tools for SAST, DAST, SCA, Secrets Scanning, and SBOM generation.

The objective of this initiative is to provide centralized visibility of the overall security posture of various production touching components within the organization. This is a stepping stone for establishing a shared security responsibility culture by providing continuous and automated visibility.

Overall Architecture

Self-serve Security Solutions

All of our security solutions are deployed as independent containers on AWS ECR so they can be pulled directly from ECR to integrate into any workflows or can be used locally by developers.

We use the following open-source tools for security scanning

• SAST → SemGrep
• SCA → OWASP Dependency Checker
• Secret Scanning → Gitleaks
• SBOM → CycloneDx

To drive self-service and ease of usability & adoption we wrote a custom wrapper on top of these tools. So our users need not worry about the underlying implementation. This gives us additional control of pushing custom rules any time and have the pipeline apply the rule on all repositories.

For example, the SAST solution asks for a few user inputs and then applies appropriate scan profiles and custom rules based on the input. This makes it easier for our users to use it without worrying about the backend implementation, like what custom rules to use, which SemGrep profiles to use, etc. It also helps us to replace the underlying tool without disturbing the existing implementation.

GitHub Repository Architecture

To achieve continuous security scanning without depending on any team we decided to

• Create an AppSec repository that has a main reusable workflow that can be used to scan any repository we wanted to scan using the standard configuration defined in security-workflow.yml
• For example, if we want to scan a dummyrepository then we create a YML file with the repo name which uses our reusable workflow and on a nightly basis
• As it triggers the security-workflow.yml file that clones the target repository which is dummy.yml and it starts scanning and archiving the report to the S3 bucket.

Security Data Visualization

The data ingestion process is complete once it is archived in the S3 bucket. The next phase is to visualize the data stored in the S3 bucket.

To solve the visualization in a near real-time manner, our Lambda function triggers on S3 PUT event and checks the relevant data, and sends it to the security dashboard.

DefectDojo

DefectDojo has inbuilt parser support for SemGrep, Gitleaks, and ODC. So all the results from these tools go to the DefectDojo dashboard via the lambda function

DependencyTrack

In the DependencyTrack, the results from the software bill of material (SBOM) are stored. DependencyTrack has inbuilt functionality to detect vulnerabilities in different components used in the application and hence it can be used to identify

• List of the components/ libraries used in the application (Inventory management)
• Vulnerabilities in used components/libraries
• Organizational license policy violation detection

Closing note

As a result, our security workflows can be integrated within GitHub Actions and can be used for PR level scanning as well and that is what is driving our shift left initiative.

For comments or feedback, you can get in touch with me over Twitter 😀

If you are interested in our work and want to solve complex problems in SaaS products, platform & cloud infrastructure engineering — we are hiring!