Setting Up an Application Security Testing Pipeline using SAST Tools

When software development moved from traditional SDLC to Agile, its goal was faster delivery to end users. It clearly served the purpose, because it did not take long for organizations world-over to jump on this bandwagon. This adoption also transformed the DevOps team to its current state.

Integration and deployment automation became commonplace in development organizations to help DevOps team in meeting the ever-increasing demand for delivering new features and fixes to production.

While this paradigm shift was taking place, security teams were seated on the sidelines waiting to be called upon when stakeholders needed a penetration test. Agile teams started to view software security testing as a roadblock. Moreover, fixing issues reported by security teams late in SDLC proved to be expensive. It was time for security teams to join the game and become an equal partner in ensuring delivery of secure software. And thus DevSecOps was born. DevSecOps integrates the security team and its capabilities into DevOps practices making security a responsibility of everyone on the team.

Security: A Milestone v/s Security: A Continuous Varying State

Traditional software development viewed security as a milestone, whereas DevSecOps views security as a continuous varying state. In DevOps, we have many continuous practices such as:

• Continuous Integration
• Continuous Deployment
• Continuous Delivery
• Continuous Testing

Security adds another continuous practice to the above list: Continuous Assurance

DevOps Is All About Pipelines

In DevOps parlance, a “pipeline” is a set of automated activities or processes that are supposed to be executed for reliably compiling, building and deploying code to test, staging or production environments. For example, a typical Continuous Integration Pipeline would include the following processes:

• Build
• Unit Testing
• Integration Testing

When you throw security in this mix, an additional step would become necessary in ensuring your application’s security:

• Static Application Security Testing (SAST)

SAST tools help you identify security defects in your code introduced by insecure functions, insecure coding practices or vulnerable and outdated dependencies in your code. SAST forms the foundation of your Application Security Pipeline. Your application’s source code is the most dynamic part of your application. It is the most likely area where security vulnerabilities could be introduced. Hence, SAST tools are central to your DevSecOps framework.

SAST analysis is executed directly on the source code. So, the tool does not require a fully functional application to perform the assessment. This makes it cheaper to fix any bugs reported by the tool. Also, SAST identifies the exact line of vulnerable code, which makes it easier to fix and reduce the time required for Root Cause Analysis (RCA).

Choosing The Right SAST Tool

There are a few factors to consider when choosing the right SAST tool that meets your DevSecOps needs.

1. Language Support: It is important to ensure that your SAST supports the programming languages you use with your organization and any languages you plan to add to your ecosystem in the future.
2. DevSecOps Readiness: The tool should support automated invocation of SAST tests through APIs, or provide integration with your CI/CD tools.
3. Ruleset Customization: It should provide for a way for security teams to integrate new security tests that suit your application and operating environment.
4. Manage False Positives: SAST tools are known for the number of false positives they generate. The tool you select should provide you a way to silence repeated alerts which you know do not pose any risk to your environment.
5. IDE Support: This is good-to-have feature, but its very useful. Some SAST tools provide IDE plugins which could help developers identify insecure code right in their IDE.
6. Alerting and Reporting: Development and security teams should be promptly notified about test failures.

Steps to Integrate an SAST tool in your pipeline

1. Run First Scan: Running the very first scan helps you build a baseline for your application.
2. Adjust Rulesets: If the application warrants additional checks or customization of existing checks, it can be during the onboarding
3. Highlight False Positives: Weeding out the false positives in this phase helps the team in fixing the real issues on hand.
4. Integrate into IDE: If the SAST tool provides IDE support, the updated rulesets should be pushed to developers’ IDEs for them to start writing secure code.
5. Integrate into Pipeline: Update your Integration pipeline to ensure that SAST scan is executed on every build requested by the DevSecOps team.

What Next?

Once your SAST integration is successful, you can further strengthen your application’s security by introducing Dynamic Application Security Testing (DAST) during later phases of the CI/CD cycle. This is typically done during the deployment process and this involves using the application like a real application user to find vulnerabilities that could be introduced by someone who does not have knowledge about an application’s internal workings.