In Application Security the focus is always on Shift Left. The theory goes that the sooner the teams can identify vulnerable code, the quicker and cheaper it can be fixed. But the reality isn’t as kind. That’s why we tend to look at application security in the same way as continuous integration and continuous delivery—”Shift Left” really means “find it at the left-most possible point.”
Keep in mind that the Security of IT Systems is Always Changing:
- The assets of the system change in value
- The techniques used to break into systems change
- Service level agreements change
- Features change
- Team members change
“Shift Left” Can Really Mean Points When:
- The system is running in production.
- A regression functional test is in progress.
- The technique hasn’t been incorporated into automatic rule sets, requiring a manual vulnerability assessment.
- The security finding isn’t actually part of code written by the development team.
- The change will require massive architecture changes and require a mitigation control in order to protect the system in the meantime.
With so many possible situations, a truly efficient and mature security software testing program needs to encapsulate multiple strategies.
One of the interesting things about this continuum is that the further one moves to the left, the less context one has of the overall usage. The further right, the less access to detail one has.
Let’s look at the various challenges of testing at each point in the cycle.
Pre-Commit Phase
While the teams are working on building the systems, the real time IDE SAST tools generally don’t have the capabilities that a full SAST scanner does. The goal at this phase is to raise developer awareness and prevent the use of risky APIs and coding practices (like hard coding passwords or secret keys).
While there are some IDE SAST tools that have more capabilities than others, most of the time they lack the full insight into the code base needed to perform data flow analysis and give comprehensive visibility.
Commit Phase
The commit phase covers the code being committed into a source code repository. Now there’s some additional context and the testing can do a deeper dive. This phase offers a great opportunity to do a slightly broader static analysis scan of the code which has changed. These scans can do more data flow analysis.
Software composition analysis is also suited for this phase.. This security test allows for automating the addition of tickets to the product backlog while doing an analysis on the impact of any vulnerabilities discovered. This analysis could lead to an automatic upgrade and can provide detail to give color on the changes needed to support mitigating controls.
Build Phase
The build phase is the packaging of the newly developed code, where larger scale tests should be run. This includes a full scale static analysis and testing the infrastructure as code.
The goal here is to get a first look insight into the overall security posture of the system with the most recent changes. These tests will usually have two different objectives:
- To perform quick runs, enabling the CI/CD pipeline to complete as fast as possible.
- To provide as much coverage as possible with longer runs.
Be sure to focus on Software Composition Analysis (SCA) in this stage. This is one of the few points where you will be able to identify and react early to new vulnerabilities from external libraries.
Test Phase
It’s vital, but challenging, to get the Test Phase right. Tool selection, tool training, and rule coverage have a significant impact on the quality of the results, the coverage of the tests, and the speed of testing. If you focus too much on speed, the risk of test cases not giving the necessary coverage will be high. The business must act within their risk and cost parameters—including compute resources, team member times, and number of team members required.
With so many opportunities for testing, this phase can be destructive in nature. These tests should be done against test systems that are as close to production systems as possible. Running these tests against production systems themselves can lead to unintended downtime and even data destruction.
When this phase is implemented properly, teams can use multiple tools during the same run. For example, a team could use end-to-end unit tests running through a DAST on an instance of the system which was instrumented using an IAST or RASP product. In this case, the team running the penetration test would leverage the SAST and SCA scans to focus on areas of potential weaknesses.
Successful tests at this stage serve two purposes.
- Prioritization of findings
- Creating new tests.
Production Phase
There are two trains of thought with production.
- The first is that production should be a little to no-touch environment. Any pen tests that are done should be non-destructive.
- The other is that it’s better that the application owners and security teams should become aware of a vulnerability before an attacker does even if there is some risk to a production system.
In this phase, the application security program is all about protecting and ensuring the security of the current deployment. Should any test find an issue, configuring a RASP or WAF to protect the application from an attack can be used as a band-aid while the underlying problem is addressed.
Remediation Optimization
A mature application security program which implements this kind of pipeline will have additional challenges:
- De-duplicating all the data that comes from the different tests so that the various asset owners can have a pared-down list of issues to remediate.
- With the volume of findings that will invariably be the result of a comprehensive testing program, prioritization by business risk is a critical element of a properly designed system.
Going Beyond Shift Left
The idea of “Shift Left” has great appeal and is a valuable buzzword for security teams. Having said that, not all vulnerabilities can be discovered at inception. Truly mature application security programs must include various checkpoints and various types of tests at various points. Although this approach requires buy-in at an organizational level and that the security tooling works with the development and support of products.
However, by aligning security measures with the overall development strategy organizations can enhance their resilience against potential threats and ensure the protection of their systems and data.