In this article we will continue the series of publications on the OWASP SAMM (Software Assurance Maturity Model), we will address the security practice related to Secure Build, within the Implementation domain.
You can also listen to this article:
Before we approach how the Secure Build practice works, let’s learn a little about the concept. The term build comes from “construct” and refers to building the software. The build process is structured along with the application pipeline.
It is important to mention that maintaining a well-defined build process, executed in an automated way, not only brings advantages in terms of security but also improves and facilitates the development process of your application, obtaining advantages such as: enabling the installation and update of new features, incorporating additional functionality, ensuring faster maintenance in case of problems, bugs, and vulnerabilities.
Secure Build according to SAMM
Now let’s see how SAMM evaluates the maturity of a secure build and what requirements are necessary to achieve maximum build maturity of your application.
According to SAMM, Secure Build (SB) is the practice of building software and applications in a standardized and repeatable way, with security components to assist.
The secure build process is divided into two main streams. The first focuses on looking for ways to fully automate the build process, including additional security checks such as SAST (Static application security testing) and DAST (Dynamic application security testing), to get faster signals in cases of security regressions, ensure more robust and secure software.
The second one is about recognizing the dependencies used in your applications, identifying possible vulnerabilities and problems, and thus identifying dependencies that may cause a negative impact on the application. At a more mature level, security checks are performed at compile time, for example, with software composition analysis (SCA) tools.
Build Process
Maturity advances in conjunction with the degree of automation of your build process, where initially you have a part of the process that needs to go through a set of manual instructions. The maximum level of maturity is reached when your entire build and compilation process is automated, going through security checks performed during software compilation.
Maturity level 1
At this first level of maturity, it is expected that the build process is well-defined and structured, broken down into a set of clear instructions that can be followed by a person or tool. Such a definition should describe the process from end-to-end, to always produce the same result.
The definition should be stored and centralized in a specific place easily accessible by a person or program, and always updated as the process evolves.
Maturity level 2
At the second level, your compilation process should be fully automated, without the need for human intervention, with the goal that compilations can be performed at any time, making it possible to reduce the probability of human error.
With the automated process, be even more careful. The confidence increases, and without the required attention, it can generate future problems. The process is automated and may require access to credentials and secrets needed to build the software, so keep the secrets encrypted and control access based on the principle of least privilege.
It is important to mention that the build process should be followed according to vendor-driven best practices.
Finally, add automated security checks such as SAST tools into the pipeline to make your automation more robust and with an extra layer of security.
Maturity Level 3
At the last level of maturity, it is expected that your security checks are adequate and well-defined, as well as your minimum criteria for build approval (build approval can be application-specific, so you can have criticality profiles according to the impact the application has on the business). Do not be afraid to “lock” the build if any predefined criteria are not met. In some cases, these criteria may be defined by the criticality of the vulnerability. One example is every time a possible critical vulnerability is identified, the pipeline “locks” and is “unlocked” as soon as the vulnerability is fixed or defined as a false positive. This process is also known as Quality Gate. However, make sure that these cases are explicitly approved and have logs and their occurrence along with a justification.
Finally, at least once a year you should select and configure tools to assess each application against its security requirements. Such as using threat modeling methods.
Software Dependencies
At a lower level of maturity, you keep track of your dependencies and their identified CVEs and move to maturity as you constantly evaluate your dependencies, identifying potential problems that dependencies can cause in the application. At the highest level of maturity, your build process goes through automated security validations.
Maturity level 1
At this first level, you are expected to have a record of all the dependencies used throughout the production environment. This record is often called the bill of materials (BOM).
Gather the following information about each dependency:
- Where it is used or referenced;
- The version used;
- License;
- Source information (repository link, author name, etc.);
- Support and maintenance status of the dependency;
- Check the logs to discover any dependencies with known vulnerabilities and update or replace them accordingly.
With this information consolidated, validate if any of your application’s dependencies are affected by any given CVE (Common Vulnerabilities and Exposures). In case of complications, replace the dependency with one with the same result.
Maturity level 2
At a second maturity level, you are expected to have an evaluation of your dependencies used. This defines usability criteria, with a degree of acceptance for projects, teams, or organizations.
Review your used dependencies regularly to ensure that:
- Dependencies remain properly licensed;
- There are no known significant vulnerabilities affecting your applications;
- The dependency is still actively supported and maintained;
- You are using a current version;
- In cases of adding a new dependency, there must be a valid reason for including it in the application.
Dependencies should be evaluated constantly for cases of the emergence of new CVEs, license changes with possible impacts on the legal use of applications, or identification of unnecessary dependencies. If any of these scenarios are identified, the team responsible for the dependency must be alerted.
We should mention that there are good practices to be followed, such as the study and implementation of the OWASP “proactive controls” that contain security measures for libraries and third-party dependencies.
Maturity level 3
Achieving the last level of maturity requires that your build process is connected to a system or tool (such as a SAST or SCA). To track third-party dependency risks, maintain a permission list of your dependencies and their approved versions, and “lock” the pipeline when dependencies outside your list attempt to be built. Integrate your build pipeline with this system or tool to define that your build “locks” whenever the included dependencies contain vulnerabilities above a defined criticality level, unless that vulnerability is evaluated as a false positive or the risk is explicitly accepted, the build should not be “unlocked”.
Finally, establish vulnerability disclosure processes with your dependency vendors, including SLAs for remediation.
What We Can Conclude
In the practice of secure development, it is important to have a well-defined Build process, with robust automation that must be closely monitored, defining rules that ensure that your application is not compiled if any rules are violated. Remember that the sooner a vulnerability or problem in the application is discovered, the less time and cost it will take to fix it.
It is also important to keep your application dependencies and dependency lists up-to-date, follow best practices, and re-evaluate their use if any issues arise that could impact the business or application.
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