Improving Application Security Using OWASP SAMM

July 3, 2023

The OWASP Software Assurance Maturity Model (SAMM) helps organizations improve their software development life cycle (SDLC) maturity. Out of the 5 major pillars of the OWASP SAMM 2.0 model, security testing appears under the verification pillar. The aim of the security testing practice is to ensure that applications published for end users and customers undergo rigorous, multi-methodological vulnerability testing and mitigation to deliver robust and secure software.

This blog post focuses on the Scalable Baseline (Stream A). Stream A is considered to be easier to implement for organizations who are starting out in their SAMM journey.

Types of Security Testing

The three types of security testing include SCA, SAST, and DAST. They are summarized as follows:

SAST and DAST testing are useful when code is being developed and before it is being put into production. SAST helps in uncovering vulnerabilities at the source code level, thereby preventing many of the vulnerabilities from getting into the final software.

DAST is used during runtime. Therefore, running DAST Scans helps find vulnerabilities and misconfigurations when the application is running. Making changes to the application web server and changing the parameters helps to mitigate many of these vulnerabilities.

SCA is mainly used for scanning third-party libraries to check for vulnerabilities or license issues that may result in the company being fined for non-compliance or regulatory concerns.

In addition to these three most popular types of security testing, two other types of security testing methodologies that are becoming more prevalent. Below are the definitions of IAST and RASP.

IAST and RASP are up-and-coming and less mainstream security testing methodologies. The number of companies in this space is limited. This is because requires a lot of effort to fine-tune the tools and setup rules to ensure that vulnerabilities are caught.

Below are examples of popular SCA, DAST, SAST, RASP and IAST tools used by various organizations.

By performing regular scans and software security testing using the various tools mentioned, organizations can easily achieve maturity level 1 (MA.1), as mentioned in the OWASP SAMM website.

To achieve even higher maturity and to progress in the SAMM journey, organizations will have to start planning for manual penetration tests at each periodic interval of the development. They can plan the security tests based on the development model followed by the organization or at the end of each sprint (usually in an Agile model). Following a regular cadence of security tests will help mitigate security vulnerabilities to a large extent. Organizations can achieve a maturity level 2 (MA.2) once this cadence is implemented, and this will allow organizations to be more conscious of the various security vulnerabilities that may be found as a result of manual testing.

Most of the SAST, DAST and SCA tools can integrate with the build pipelines such as Jenkins, GitHub, Team City, etc. through plugins or other methods as described in the tool documentation. Using the Shift-Left or popularly known DevSecOps methodology, one can automate the scanning and testing of the code by setting various failure criteria depending on the organization’s risk appetite before being pushed to production. This is the final level, and it is the hardest to achieve because it requires a cultural and procedural shift in the way software is developed and security testing is conducted in the organization. Once this is successfully implemented and developers are trained in the Shift-Left way of working, organizations can successfully move to maturity level 3 (MA.3).

During various SDLC assessments and client engagements, Optiv has observed that many security teams install security tools and are happy to automate the scans with a baseline configuration performed at the time of installation. In many cases, we see that effort is not made to fine-tune the tools to obtain better results. This can lead to missed vulnerabilities or the generation of more false positives. Developers should consistently implement, tune, and update Al tools to keep up with the development changes and ensure that scanners catch recently published vulnerabilities.

Real-World Example

Let's take the example of using a SAST tool to scan the codebase for a company. If the company uses custom routines to filter special characters, which may prevent SQL injection, cross-site scripting (XSS), and other input validation findings, this routine should be taught to the tool once a baseline scan is run with the initial configuration. If a scan is run without fine-tuning the tool with the new input routine, the scanner may flag Reflected or Persistent XSS in the code, which would be a false positive. Giving such a report to developers will cause them to trust the tool less—thus negating the benefits that the SAST tool may bring—for it is not tuned as per the organization’s development processes.

Note: When selecting tools, use input from security-focused technical staff, as well as developers and security managers, and review the results with stakeholders. If required, you can complete an in-depth comparison of multiple tools before deciding on a final tool that serves the organization’s security testing criteria.

Conclusion

Optiv can help companies improve their SDLC maturity and perform security testing on their critical applications to identify and mitigate security vulnerabilities. Contact Optiv’s Application Security Practice to know more about SDLC and security testing offerings.

References
https://owaspsamm.org/model/verification/security-testing/