new blog on benchmark analysis + updates to the BSIMM-SAMM mapping blog

content/en/blog/samm-bsimm-mapping.md

@@ -12,32 +12,28 @@ author = "Aram Hovsepyan, Maxim Baele"
 
 #### Introduction
 
-The Building Security In Maturity Model (BSIMM) and OWASP Software Assurance Maturity Model (SAMM) share a unique history. Both were conceived around 2008-2009, during the early days of structured application security maturity frameworks. Over time, however, these two models have evolved independently, with distinct conceptual differences. We have previously explored these differences in detail (reference). Despite their divergence, both frameworks aim to help organizations enhance their application security programs. Recognizing this shared mission, the OWASP SAMM core team has developed a detailed mapping between SAMM and BSIMM, highlighting their similarities and points of alignment.
+The Building Security In Maturity Model (BSIMM) and OWASP Software Assurance Maturity Model (SAMM) share a common history. Both were conceived around 2008-2009 and are based on OpenSAMM, which was created by Pravir Chandra. Over time, however, these two models have evolved independently, with distinct conceptual differences. We have previously {{<external-link "https://owaspsamm.org/blog/2020/10/29/comparing-bsimm-and-samm/" "explored these differences in detail">}}. Despite their divergence, both frameworks aim to help organizations enhance their application security programs. Recognizing this shared mission, we have developed a detailed mapping between SAMM and BSIMM, highlighting their similarities and points of alignment.
 
 #### Mapping Granularity
-The mapping between SAMM and BSIMM follows the same approach as the SAMM-to-NIST SSDF mapping, aligning BSIMM activities with SAMM streams. This approach highlights the conceptual and structural differences between the two frameworks. Rather than mapping individual activities at specific maturity levels, the SAMM-BSIMM mapping groups BSIMM activities under SAMM streams, which are broader thematic groupings of security practices.
-
-This methodology underscores the divergence between SAMM and BSIMM despite their common origins. While SAMM organizes its framework into streams that emphasize holistic security goals, BSIMM provides a catalog of specific activities focused on observable behaviors in software security initiatives. The mapping exercise not only illustrates the differing perspectives but also provides valuable insight into how organizations can bridge these frameworks to create a cohesive and effective application security program.
+The mapping between SAMM and BSIMM follows a similar approach as we did during the SAMM to NIST SSDF mapping. We have mapped BSIMM activities to SAMM streams rather than SAMM activities. This choice highlights the conceptual and structural differences between the two frameworks. Rather than mapping individual activities at specific maturity levels, the SAMM-BSIMM mapping groups BSIMM activities under SAMM streams. SAMM organizes its framework into streams. Streams cover different aspects of a practice and have their own objectives, aligning and linking the activities in the practice over the different maturity levels. BSIMM provides a catalog of specific activities focused on observable behaviors in software security initiatives throughout the organizations that have committed to BSIMM.
 
 #### How Similar Are BSIMM and SAMM?
 
-Despite their conceptual differences, the mapping effort demonstrates that SAMM and BSIMM remain relatively aligned in terms of content. Many activities defined in BSIMM have direct equivalents in SAMM, and vice versa. This overlap underscores the shared priorities of both models in fostering secure software development practices.
-
-However, exploring the activities unique to one model offers intriguing insights. These differences reflect the distinct philosophies of SAMM and BSIMM and provide opportunities for organizations to consider adopting complementary practices from each framework.
+Despite their conceptual differences, the mapping effort demonstrates that SAMM and BSIMM remain relatively aligned in terms of content. Many activities defined in BSIMM have direct equivalents in SAMM, and vice versa. However, exploring the activities unique to one model offers interesting insights. The differences also provide valuable feedback to the SAMM core team who could consider adding some of these missing activities to the SAMM model.
 
 #### BSIMM Activities Not Present in SAMM
 
 ##### 1. Strategy and Metrics: SM3.2 – Make SSI Efforts Part of External Marketing
 
-This BSIMM activity emphasizes the integration of software security initiatives (SSI) into external marketing strategies. By showcasing robust application security practices to the public, organizations can enhance their reputation and foster a security-aware culture internally. This approach draws on the psychological principle known as the Pygmalion Effect, where higher expectations from individuals or teams often lead to improved performance. When employees recognize that their organization values and promotes security excellence, they are more likely to take pride in their work and strive for continuous improvement.
+This BSIMM activity emphasizes the integration of software security initiatives (SSI) into external marketing strategies. By showcasing robust application security practices to the public, organizations can enhance their reputation and foster a security-aware culture internally. This approach draws on the psychological principle known as the {{<external-link "https://en.wikipedia.org/wiki/Pygmalion_effect" "Pygmalion Effect">}}, where higher expectations from individuals or teams often lead to improved performance. When employees recognize that their organization values and promotes security excellence, they are more likely to take pride in their work and strive for continuous improvement.
 
-While SAMM does not explicitly include this activity, introducing it as a quality criterion could be beneficial. Encouraging organizations to communicate their application security achievements externally could positively influence the overall security culture, even if making it mandatory might not align with SAMM’s flexible, organization-specific approach.
+While SAMM does not explicitly include this activity, introducing it as a quality criterion could be beneficial. First of all, this would reinforce the reputation of SAMM being an industry-wide standard application security program. Encouraging organizations to communicate their application security achievements externally could also positively influence the overall security culture. As the saying goes, "Culture eats strategy for breakfast!".
 
 ##### 2. Software Environment: SE3.2 – Code Protection to Safeguard Intellectual Property
 
-This BSIMM activity focuses on protecting intellectual property by making codebases harder to reverse engineer. Techniques such as code obfuscation are particularly relevant for mobile applications and front-end web logic. SAMM currently lacks a direct analog to this activity, reflecting a divergence in focus.
+This BSIMM activity focuses on protecting intellectual property by making codebases harder to reverse engineer. Techniques such as code obfuscation are particularly relevant for mobile applications and front-end code (typically in Javascript). SAMM currently lacks a direct analog to this activity, reflecting a divergence in focus.
 
-The utility of this activity can be debated. On one hand, relying solely on security by obscurity is discouraged as a standalone strategy. However, when viewed through the lens of the defense-in-depth principle, code protection adds another layer of security. By increasing the effort required for attackers to reverse-engineer code, organizations can make exploitation more challenging. While SAMM does not prioritize such activities, incorporating code protection into broader security design considerations could enhance the model’s coverage of intellectual property protection.
+The utility of this activity can be debated. On one hand, relying solely on security by obscurity is discouraged as a standalone strategy. However, when viewed through the lens of the defense-in-depth principle, code protection adds another layer of security. By increasing the effort required for attackers to reverse-engineer code, organizations can make exploitation more challenging.
 
 ##### 3. Attack Models: AM2.9 – Monitor Automated Asset Creation
 Yet another BSIMM activity not found in SAMM is AM2.9: Monitor Automated Asset Creation. This activity focuses on implementing technology controls that provide a continuously updated view of assets created by engineering teams. These assets include network infrastructure, machines, software components, and related resources. The ability to monitor automated asset creation is crucial for several reasons:
@@ -49,9 +45,7 @@ This activity could align well with SAMM under the Operations business function,
 #### SAMM Activities Not Present in BSIMM
 ##### 1. Secret Management: I-SD-B
 
-One notable SAMM activity that does not have a direct equivalent in BSIMM is I-SD-B: Secret Management. This activity explicitly focuses on maintaining strong secret management hygiene, including practices such as managing the lifecycle of secrets, detecting potentially leaked secrets, and ensuring secure storage and access mechanisms. While BSIMM references aspects of secret management in several activities—such as SFD1.1 (Integrating and delivering security features), SE3.9 (Protecting the integrity of development environments), and SE2.7 (Using orchestration and virtualized environments)—it does not explicitly define a dedicated activity for secret management.
-
-Given the widespread adoption of vault technologies (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault), secret management capabilities are increasingly becoming out-of-the-box features in many organizations. This pervasiveness may have influenced BSIMM’s decision to integrate secret management topics indirectly across various activities rather than defining a standalone activity.
+One notable SAMM activity that does not have a direct equivalent in BSIMM is I-SD-B: Secret Management. This activity explicitly focuses on maintaining strong secret management hygiene, including practices such as managing the lifecycle of secrets, detecting potentially leaked secrets, and ensuring secure storage and access mechanisms. BSIMM does reference aspects of secret management in several activities. For instance, SFD1.1 (Integrating and delivering security features), SE3.9 (Protecting the integrity of development environments), and SE2.7 (Using orchestration and virtualized environments). However BSIMM does not explicitly define a dedicated activity for secret management. We believe the root cause for this is BSIMM's descriptive nature. It is indeed plausible to think that organizations are unlikely to have efforts focused on secret management in isolation, rather in combination with concrete activities.
 
 #### Conclusion
 The mapping between BSIMM and OWASP SAMM reveals significant overlap and alignment between the two frameworks, highlighting their shared roots and complementary goals. At the same time, exploring activities unique to each model provides valuable opportunities for mutual enrichment.