Continuing the series of publications on the OWASP SAMM framework (Software Assurance Maturity Model), in this article, we will address the practice of Security Testing within the Verification domain. If you still have no idea about the composition and organization of the framework, I recommend reading our first article, which explains in more detail in this link.
Analyzing the image that follows, we can see that the OWASP SAMM framework has five main domains, each one with three different security practices. These are segmented into two different flows A and B, with the flows divided into three levels of security maturity.
Image 1: Composition and organization of the OWASP SAMM 2.0 framework
In the case of Security Testing practice, we have:
- Scalable Baseline – Stream A
This flow handles the management of automated tests. The objective is to show how the use of tools like SCA, SAST, DAST, and others is important to cover a vast area of code written in different application modules.
- SCA (Software Composition Analysis) – Compares the entire structure of libraries that compose the software with an updated list of libraries that have been reported as vulnerable and recommends replacements or updates;
- SAST (Static Application Security Test) – It is a test done in the software code, before the build and deploy phases. It scans for code patterns known to contain vulnerabilities;
- DAST (Dynamic Application Security Test) – This test happens with the application already deployed and running. The tool triggers several malicious code insertions and observes their behavior to identify possible exploitable flaws.
The first level of maturity is reached when these tests are entirely integrated into the CI/CD pipeline and are triggered automatically with every change released in the application code.
Automated tools can usually be reprogrammed for better accuracy. As they generate their results, it is possible to improve their filters, making them more efficient in their analysis and thus increasing the security maturity level to the second level.
At its highest level of maturity, the tests are already covering all application modules, they are triggered automatically and the tools’ filters are constantly improved, increasing the accuracy of the results with a false positives reduction.
- Deep Understanding – Stream B
This is the manual work flow, the security professional in charge of the code review task and the pentester. Because manual review is slow and difficult to scale, reviewers prioritize testing components based on their risk, recent relevant changes, or upcoming major releases.
Common examples of high-risk functionality include authentication modules, access control enforcement points, session management schemes, external interfaces, and input validators.
The first level of security maturity is reached when security professionals work through the code review and findings analysis processes.
Findings are the pre-stage of a detected vulnerability. It is the result of the tests performed by automation tools, and then, they can be discarded as false positives or reported as real vulnerabilities.
To increase the level of security maturity to the second level, the organization is recommended pentesting their applications in homologation environments.
It is also recommended to promote “bug bounty” programs, where the application is exposed and hackers are invited to attack it in order to discover the existing vulnerabilities in exchange for prizes.
At its highest stage of maturity, the organization already has security testing processes fully integrated into the production chain, their testing tools are constantly trained and improved, delivering increasingly accurate results.
As a result, security professionals have more time to dedicate to secure architecture refinement processes, application of security requirements in software development, and applications are designed with fewer bugs and vulnerabilities from the outset.
Conviso Platform has all the necessary resources for the management of code review processes, findings, and vulnerabilities analysis can become as simple as possible.
It also has its own automated testing tools, but also allows integration with the ones most used in the market.
In the following image, we can see how Conviso Platform lists the vulnerabilities reported by security professionals:
Image 2: Vulnerabilities reported in Conviso Platform
Conclusion about Security Testing
It is possible to understand that application testing processes go far beyond automated tests such as SCA, SAST and DAST. Although they are a very important part of the endeavor towards greater maturity in application security, they are only half of the process and cannot have better results without the constant intervention of professionals who are specialists in the areas of code review and pentesting.
In addition, the entire S-SDLC chain benefits from greater integration between these processes, creating a symbiosis where, as a security practice gains maturity, some mechanisms will be automatically created and will directly or indirectly help graduating in others security practices referenced by SAMM.
SAMM article series
- Governance according to SAMM: Strategy and Metrics in Application Security
- Governance according to SAMM: Policies and Conformities in Application Security
- Governance According to SAMM: Application Security Education and Guidance
- Design according to SAMM: Threat Modeling in Application Security
- Design According to SAMM: Security Requirements in AppSec
- Design according to SAMM – Secure Architecture in Application Security
- Implementation according to SAMM: Secure Build in Application Security
- Implementation according to SAMM: Secure Deployment in Application Security
- Implementation According to SAMM: Defect Management in AppSec
- Verification according to SAMM: Application Security Architecture Analysis
- Verification according to SAMM: Requirements-Driven Testing in Application Security
- Verification according to SAMM: Security Tests in Application Security
- Operations according to SAMM: Application Security Incident Management
- Operations according to SAMM: Environment Management and Application Security
- Operations according to SAMM: Operational Management in Application Security