+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-A Stream A: Deployment Process
A repeatable and consistent deployment process ensures you only deploy correct software artifacts to production. It also paves the way for representative test environments prior to production.
1. Ħarsa ġenerali
| Titlu |
Standard |
|
I-SD-1-A Use a repeatable deployment process
|
Maturity level 1 objective of the practice: Deployment processes are fully documented. Benefit: Limited risk of human error during the deployment process, minimizing security issues Short description: Formalize the deployment process and secure the used tooling and processes. Define the deployment process over all stages, breaking it down into a set of clear instructions to either be followed by a person or an automated tooling. The deployment process definition should describe the whole process end-to-end so that it can be consistently followed each time to produce the same result. The definition is stored centrally and accessible to all relevant personnel. Do not store or distribute multiple copies, some of which may become outdated. Deploy applications to production either using an automated process, or manually by personnel other than the developers. Ensure that developers do not need direct access to the production environment for application deployment. Review any deployment tools, ensuring that they are actively maintained by vendors and up to date with security patches. Harden each tool's configuration so that it is aligned with vendor guidelines and industry best practices. Given that most of these tools require access to the production environment, their security is extremely critical. Ensure the integrity of the tools themselves and the workflows they follow, and configure access rules to these tools according to the least privilege principle. Have personnel with access to the production environment go through at least a minimum level of training or certification to ensure their competency in this matter. ResultsMetricsCostsTBS. Personnel- Administrator
- Security Engineer
|
|
I-SD-2-A Automate deployment and integrate security checks
|
Maturity level 2 objective of the practice: Deployment processes include security verification milestones. Benefit: Efficient deployment process with integrated security tools Short description: Automate the deployment process over all stages and introduce sensible security verification tests. Automate the deployment process to cover various stages, so that no manual configuration steps are needed and the risk of isolated human errors is eliminated. Ensure and verify that the deployment is consistent over all stages. Integrate automated security checks in your deployment process, e.g. using Dynamic Application Security Testing (DAST) and vulnerability scanning tools. Also, verify the integrity of the deployed artefacts where this makes sense. Log the results from these tests centrally and take any necessary actions. Ensure that in case any defects are detected, relevant personnel is notified automatically. In case any issues exceeding predefined criticality are identified, stop or reverse the deployment either automatically, or introduce a separate manual approval workflow so that this decision is recorded, containing an explanation for the exception. Account for and audit all deployments to all stages. Have a system in place to record each deployment, including information about who conducted it, the software version that was deployed, and any relevant variables specific to the deploy. ResultsMetricsCostsTBS. Personnel- Administrator
- Security Engineer
|
|
I-SD-3-A Verify the integrity of deployment artifacts
|
Maturity level 3 objective of the practice: Deployment process is fully automated and incorporates automated verification of all critical milestones. Benefit: Assured integrity of artifacts being deployed to production Short description: Automatically verify the integrity of all deployed software, regardless of whether it's internally or externally developed. Take advantage of binaries being signed at the build time and include automatic verification of the integrity of software being deployed by checking their signatures against trusted certificates. This may include binaries developed and built in-house, as well as third-party artifacts. Do not deploy artifacts if their signatures cannot be verified, including those with invalid or expired certificates. If the list of trusted certificates includes third-party developers, check them periodically, and keep them in line with the organization's wider governance surrounding trusted third-party suppliers. Manually approve the deployment at least once during an automated deployment. Whenever a human check is significantly more accurate than an automated one during the deployment process, go for this option. ResultsMetricsCostsTBS. Personnel- Security Engineer
- Administrator
|
1.1 Referenzi
1.2 Rekwiżiti identifikati
1.3 Regolamenti relatati
2. Rekwiżiti identifikati
3. Regolamenti relatati
Regolamenti
| Sors |
Regolamentazzjoni |
- 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. - OWASP Application Security Verification Standard (ASVS) 5.0.0, May 2025, from OWASP/ASVS: © 2008-2025 The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: divided into sections and converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0, January 2024, from OWASP/masvs: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0, August 2026, from OWASP/maswe: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged, linked to the MASVS controls they map to. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, June 2026, from OWASP/mastg: © The OWASP Foundation, licensed under CC BY-SA 4.0. The tests and best practices only, without code samples, images, tools or apps. Changes: converted into the GRCA format, the wording unchanged; references to other pages of the MASTG as links to mas.owasp.org; the weakness of each test in the numbering of MASWE v1 and linked to it. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Software Assurance Maturity Model (SAMM) v2.2.0, July 2026, from owaspsamm/core: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged; short codes (G-SM-1-A) built from the model, the assessment questions as assessment procedures of their activities. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Top 10:2025, from OWASP/Top10: © 2003-2025 The OWASP® Foundation, Inc., licensed under CC BY-SA 4.0. The ten categories, without the icons. Changes: converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well. The names of the mapped CWEs (Common Weakness Enumeration): © 2006–2026 The MITRE Corporation. License: The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. See the CWE Terms of Use. CWE™ is a trademark of The MITRE Corporation.
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. - OWASP Application Security Verification Standard (ASVS) 5.0.0, Mai 2025, aus OWASP/ASVS: © 2008-2025 The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0, Januar 2024, aus OWASP/masvs: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0, August 2026, aus OWASP/maswe: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert, mit den MASVS-Controls verknüpft, denen sie zugeordnet sind. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, Juni 2026, aus OWASP/mastg: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Nur die Tests und Best Practices, ohne Codebeispiele, Bilder, Werkzeuge und Apps. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert; Verweise auf andere Seiten des MASTG als Links zu mas.owasp.org; die Schwachstelle jedes Tests in der Nummerierung der MASWE v1 und mit ihr verknüpft. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Software Assurance Maturity Model (SAMM) v2.2.0, Juli 2026, aus owaspsamm/core: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert; Kürzel (G-SM-1-A) aus dem Modell gebildet, die Assessment-Fragen als Prüfverfahren ihrer Aktivitäten. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Top 10:2025, aus OWASP/Top10: © 2003-2025 The OWASP® Foundation, Inc., lizenziert unter CC BY-SA 4.0. Die zehn Kategorien, ohne die Symbole. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0. Die Namen der zugeordneten CWEs (Common Weakness Enumeration): © 2006–2026 The MITRE Corporation. MITRE erlaubt die Nutzung für Forschung, Entwicklung und kommerzielle Zwecke, wenn jede Kopie den Urheberrechtsvermerk und die Lizenz enthält; maßgeblich ist der englische Wortlaut der Lizenz oben und die CWE Terms of Use. CWE™ ist eine Marke der MITRE Corporation.
|