+Implementation
---+I-SB Secure Build
------+I-SB-A Stream A: Build Process
---------+I-SB-1-A Define a consistent build process
---------+I-SB-2-A Automate the build process
---------+I-SB-3-A Enforce a security baseline during build
------+I-SB-B Stream B: Software Dependencies
---------+I-SB-1-B Identify application dependencies
---------+I-SB-2-B Review application dependencies for security
---------+I-SB-3-B Test application dependencies
---+I-SD Secure Deployment
------+I-SD-A Stream A: Deployment Process
---------+I-SD-1-A Use a repeatable deployment process
---------+I-SD-2-A Automate deployment and integrate security checks
---------+I-SD-3-A Verify the integrity of deployment artifacts
------+I-SD-B Stream B: Secret Management
---------+I-SD-1-B Protect application secrets in configuration and code
---------+I-SD-2-B Include application secrets during deployment
---------+I-SD-3-B Enforce lifecycle management of application secrets
---+I-DM Defect Management
------+I-DM-A Stream A: Defect Tracking
---------+I-DM-1-A Track security defects centrally
---------+I-DM-2-A Rate and track security defects
---------+I-DM-3-A Enforce an SLA for defect management
------+I-DM-B Stream B: Metrics and Feedback
---------+I-DM-1-B Define basic defect metrics
---------+I-DM-2-B Define advanced defect metrics
---------+I-DM-3-B Use metrics to improve the security strategy

Implementation

Implementation is focused on the processes and activities related to how an organization builds and deploys software components and their related defects.

Activities within the Implementation function have the most impact on the daily life of developers. The joint goal is to ship reliably working software with minimum defects.

1. Pārskats

I-SB Secure Build

Short description: This practice focuses on creating a consistently repeatable build process and accounting for the security of application dependencies.

The Secure Build (SB) practice emphasizes the importance of building software in a standardized, repeatable manner, and of doing so using secure components, including 3rd party software dependencies.

The first stream focuses on removing any subjectivity from the build process by striving for full automation. An automated build pipeline can include additional automated security checks such as SAST and DAST to gain further assurance and flag security regressions early by failing the build, for example.

The second stream acknowledges the prevalence of software dependencies in modern applications. It aims to identify them and track their security status in order to contain the impact of their insecurity on an otherwise secure application. In an advanced form, it applies similar security checks to software dependencies as to the application itself.
I-SD Secure Deployment

Short description: This practice focuses on increasing the security of software deployments to the production environment and the supporting secrets.

One of the final stages in delivering secure software is ensuring the security and integrity of developed applications are not compromised during deployment. The Secure Deployment (SD) practice focuses on this. To this end, the practice’s first stream focuses on removing manual error by automating the deployment process as much as possible, and making its success contingent upon the outcomes of integrated security verification checks. It also fosters Separation of Duties by making adequately trained, non-developers responsible for deployment.

The second stream goes beyond the mechanics of deployment, and focuses on protecting the privacy and integrity of sensitive data, such as passwords, tokens, and other secrets, required for applications to operate in production environments. In its simplest form, suitable production secrets are moved from repositories and configuration files into adequately managed digital vaults. In more advanced forms, secrets are dynamically generated at deployment time and routine processes detect and mitigate the presence of any unprotected secrets in the environment.
I-DM Defect Management

Short description: This practice focuses on managing security defects in software and their associated metrics.

The Defect Management (DM) practice focuses on collecting, recording, and analyzing software security defects and enriching them with information to drive metrics-based decisions.

The practice’s first stream deals with the process of handling and managing defects to ensure released software has a given assurance level. The second stream focuses on enriching the information about the defects and deriving metrics to guide decisions about the security of individual projects and of the security assurance program as a whole.

In a sophisticated form, the practice requires formalized, independent defect management and real-time, correlated information to detect trends and influence security strategy.

1.1 Atsauces

1.2 Identificētās prasības

1.3 Saistītie tiesību akti

2. Identificētās prasības

Prasības

3. Saistītie tiesību akti

Tiesību akti
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.