Most organizations approach software security as an afterthought—implementing ad-hoc fixes and conducting periodic audits rather than building systematic security capabilities. This reactive stance creates a fundamental gap between what security teams believe they're accomplishing and what enterprises actually need when evaluating vendors. For companies selling to enterprise clients in 2026, demonstrating measurable software security maturity has become non-negotiable. Enterprise buyers expect evidence-based assurance that their vendors have embedded security throughout the software development lifecycle, not just bolted it on before audits.

‍

The Building Security In Maturity Model (BSIMM) addresses this gap by providing a data-driven framework for measuring and benchmarking software security initiatives. Unlike compliance frameworks that prescribe specific controls, BSIMM documents what organizations actually do to achieve software security maturity—making it particularly valuable for vendors who need to demonstrate credible security practices to enterprise clients while meeting data protection obligations under frameworks like ISO 27001, SOC 2, and GDPR.

‍

What is the BSIMM Framework?

BSIMM is a descriptive model designed to help organizations measure and improve their software security initiatives. Rather than prescribing a standardized set of controls, BSIMM is built by studying real-world practices used by hundreds of organizations across various industries. This empirical foundation distinguishes BSIMM from prescriptive frameworks—it reflects actual implementation patterns observed in mature software security programs, not theoretical ideals.

‍

The framework focuses specifically on software security: the processes, practices, and organizational structures required to build secure applications. This includes secure coding practices, architecture analysis, security testing, vulnerability management, and governance activities. BSIMM measures what organizations do throughout the software development lifecycle to reduce security risk, making it directly relevant to data protection requirements that depend on secure development practices.

‍

Origin and Evolution

BSIMM and OWASP SAMM share common history, both conceived around 2008-2009 and based on OpenSAMM, created by Pravir Chandra. The framework emerged from collaboration between security leaders including Gary McGraw from Cigital (now part of Synopsys) and Brian Chess from Fortify Software. The first BSIMM release in 2009 documented software security practices observed across nine firms.

‍

BSIMM15, published in January 2025, provides analysis of 121 organizations. This evolution demonstrates the framework's continued relevance—each iteration incorporates data from more organizations, tracks emerging practices, and adapts to evolving threats. The framework incorporates data from hundreds of assessments in more than 100 organizations, describing the work of thousands of security professionals and developers.

‍

Recent BSIMM iterations reflect contemporary security challenges: supply chain risk management, software bill of materials (SBOM) creation, cloud-native security automation, and vendor security expectations. The framework evolves as participating organizations adopt new practices, creating a living dataset that reflects current industry behavior rather than static recommendations.

‍

Core Structure: Domains, Practices, Activities

BSIMM is divided into four domains: Governance, Intelligence, SSDL Touchpoints, and Deployment. The framework is organized into 12 practices, three in each of four domains. These practices encompass specific focus areas within each domain:

‍

• Governance addresses organizational structure, policy, and training—establishing the foundation for software security initiatives through strategy and metrics, compliance and policy, and security training programs.

‍

• Intelligence covers activities that inform security decisions: attack modeling, security features and design review, and standards and requirements definition. This domain ensures security decisions are based on threat intelligence and risk analysis.

‍

• SSDL Touchpoints (Secure Software Development Lifecycle Touchpoints) encompasses technical activities embedded directly into development: architecture analysis, code review and static analysis, and security testing. These practices represent hands-on security work during software creation.

‍

• Deployment addresses operational security: penetration testing, software environment management, and configuration management. This domain covers security activities that occur as software moves to production and throughout its operational lifecycle.

‍

Within these 12 practices, BSIMM tracks over 120 discrete activities—specific, observable actions that organizations perform. Activities are leveled based on observation frequency across the dataset, with Level 1 activities representing practices observed in many organizations and Level 3 activities representing advanced practices observed in fewer, more mature programs.

‍

The assessment output generates a scorecard showing which activities an organization performs, how this compares to peer organizations, and where gaps exist relative to industry benchmarks. This data-driven comparison enables organizations to prioritize improvements based on what similar organizations have successfully implemented.

‍

Why BSIMM Matters for Data Protection Standards

1) Bridging Software Security and Data Protection

Data protection regulations—GDPR, HIPAA, ISO 27001, SOC 2—require organizations to implement technical and organizational measures to protect data throughout its lifecycle. These requirements translate directly to software development practices: secure coding to prevent vulnerabilities that could expose data, vulnerability management to address weaknesses before exploitation, access controls embedded in application architecture, and incident response capabilities to detect and respond to breaches.

‍

BSIMM addresses these requirements through its focus on software security practices. The framework's Intelligence domain covers risk assessment and security requirements definition. SSDL Touchpoints practices ensure security controls are implemented during development rather than added afterward. Deployment practices address operational security and incident response. For organizations subject to data protection standards, BSIMM provides a systematic approach to building the software security capabilities those standards require.

‍

This alignment matters particularly for B2B vendors. When enterprise clients conduct vendor security assessments, they evaluate whether suppliers have implemented appropriate technical measures to protect client data processed by vendor software. Demonstrating BSIMM-aligned practices provides evidence that your organization has systematic software security capabilities, not just compliance documentation.

‍

2) Supporting Enterprise Client Expectations

Expectations for strong vendor security practices grew by 21% as firms held vendors to standards similar to those they use internally. Enterprise clients increasingly demand transparency into vendor software security practices. Security questionnaires, vendor risk assessments, and due diligence processes probe specific capabilities: Do you perform code reviews? How do you manage third-party dependencies? What security testing occurs before release? How quickly do you remediate vulnerabilities?

‍

Organizations using BSIMM can answer these questions with specificity backed by benchmarking data. Rather than providing generic assurances, vendors can demonstrate where their practices align with industry norms, where they exceed typical maturity levels, and how they're systematically improving. This transparency builds trust with enterprise clients who understand that software security is an ongoing discipline, not a one-time certification.

‍

BSIMM assessments also provide a common language for discussing software security maturity. When enterprise clients themselves use BSIMM or similar frameworks, vendors who can discuss their practices using the same terminology demonstrate sophistication that generic compliance statements cannot convey.

‍

3) Benchmarking and Continuous Improvement

A BSIMM assessment empowers organizations to analyze and benchmark their software security program against 100+ organizations across several industry verticals. This benchmarking capability addresses a fundamental challenge in software security: determining whether your investment and effort are appropriate relative to the threats you face and the maturity of your peers.

‍

The BSIMM dataset enables comparison by industry vertical, organization size, and specific security context. Organizations can identify practices that peer companies have successfully implemented, prioritize investments based on observed effectiveness, and demonstrate progress over time through periodic reassessments. This data-driven approach to prioritization helps security leaders make resource allocation decisions backed by empirical evidence rather than vendor marketing or theoretical recommendations.

‍

For enterprise sales scenarios, benchmarking data provides compelling evidence in RFP responses and client presentations. Demonstrating that your software security practices align with or exceed industry norms—backed by objective assessment data—differentiates your organization from competitors who offer only compliance certifications or generic security assurances.

‍

4) Alignment with Risk Management and Development Lifecycle

BSIMM's structure directly addresses the two dimensions enterprise clients evaluate most rigorously: risk management capabilities and secure development lifecycle implementation.

‍

The Intelligence and Governance domains capture risk management activities: identifying relevant attack vectors, defining security requirements based on threat analysis, establishing metrics that track security posture, and maintaining compliance with regulatory obligations. These practices demonstrate that security decisions are informed by risk analysis, not guesswork.

‍

The SSDL Touchpoints domain addresses secure development lifecycle requirements: architecture review to identify design-level vulnerabilities, code review to catch implementation flaws, security testing to validate control effectiveness, and standards to ensure consistency across development teams. Organizations that implement these practices systematically reduce the likelihood of shipping vulnerabilities that could compromise client data.

‍

This alignment supports data protection obligations in practical terms. GDPR requires "security by design and by default"—a principle directly addressed through BSIMM's architecture analysis and security features practices. SOC 2 requires documented software development lifecycle controls—exactly what BSIMM's SSDL Touchpoints domain measures. ISO 27001 requires risk-based security controls throughout system development—the foundation of BSIMM's Intelligence domain.

‍

How BSIMM Works in Practice

1) Conducting a BSIMM Assessment

BSIMM assessments are conducted through structured interviews with stakeholders across the software security organization: security architects, application security engineers, development managers, compliance personnel, and security leadership. Synopsys manages assessments based on interviews during a BSIMM assessment, with data anonymized and added to a data pool where it is analyzed statistically.

‍

The assessment process documents which of the 120+ BSIMM activities your organization currently performs. Assessors gather evidence through interviews, documentation review, and observation of actual practices. The output is a scorecard showing your organization's activity profile, maturity level within each practice, and comparison to the benchmark dataset.

‍

Gap analysis identifies activities commonly observed in peer organizations that your organization has not yet implemented. This analysis prioritizes opportunities based on observation frequency—practices that most organizations at your maturity level perform represent logical next steps. The assessment also identifies areas where your organization exceeds typical maturity, which can be leveraged in enterprise sales conversations.

‍

Organizations typically conduct initial baseline assessments, then reassess annually or biennially to track progress. This longitudinal data demonstrates continuous improvement—a key indicator of mature security programs that enterprise clients value highly.

‍

2) Integrating into the Software Development Lifecycle

BSIMM implementation focuses on embedding security practices into existing development workflows rather than creating parallel security processes. SSDL Touchpoints practices integrate directly into development activities: architecture review occurs during design phases, code review integrates with pull request workflows, security testing runs within CI/CD pipelines.

‍

The Strategy & Metrics practice from the Governance domain establishes measurements that track security throughout the development lifecycle: number of vulnerabilities identified by severity, time-to-remediation for different risk levels, coverage of security testing across codebases, training completion rates for development teams. These metrics provide visibility into security posture and drive accountability for security outcomes.

‍

Governance practices define roles and responsibilities, ensuring security activities occur consistently across development teams. This includes establishing security champion programs—developers with security expertise who embed within product teams. Firms with security champion programs earned an average 25% higher BSIMM score than firms without one, demonstrating that distributed security expertise significantly improves overall security maturity.

‍

3) Mapping to Data Protection and Enterprise Client Requirements

Specific BSIMM practices map directly to controls required by data protection standards and enterprise client security requirements:

‍

Training practices address security awareness requirements found in ISO 27001, SOC 2, and GDPR. Organizations must demonstrate that personnel handling sensitive data understand security responsibilities—BSIMM's training activities provide evidence of systematic security education.

‍

Code review and static analysis address secure development requirements. SOC 2 CC7.1 requires organizations to evaluate security implications of system changes before implementation. BSIMM's code review practices demonstrate this control through documented, systematic review processes.

‍

Incident response activities within the Deployment domain address data breach readiness requirements under GDPR and breach notification requirements under various regulations. Organizations must demonstrate capabilities to detect, respond to, and remediate security incidents—BSIMM activities document these operational capabilities.

‍

Vendor security practices map to supply chain risk requirements increasingly common in enterprise contracts. BSIMM activities addressing third-party code, dependency management, and vendor assessments demonstrate systematic approaches to supply chain security—a growing concern following high-profile supply chain attacks.

‍

When responding to enterprise RFPs or completing vendor security questionnaires, organizations can map specific questions to implemented BSIMM activities, providing concrete evidence of security capabilities rather than generic assurances.

‍

4) Using BSIMM for Vendor and Supply Chain Security

Organizations selling to enterprise clients face vendor security assessments themselves, but they also bear responsibility for their own supply chain security. BSIMM practices within the Intelligence and Deployment domains address supplier risk: evaluating security of third-party components, managing open-source dependencies, assessing vendor security practices, and monitoring the software environment for introduced vulnerabilities.

‍

Organizations building SBOMs increased by 22% from last year, reflecting growing recognition that organizations must understand what components comprise their software. BSIMM's supply chain activities provide a framework for systematically addressing this requirement—increasingly mandatory in enterprise contracts and regulatory requirements.

‍

Identifying and controlling open-source risk increased by just under 10% from last year, demonstrating that mature organizations are implementing systematic processes for managing open-source risk rather than treating it as an afterthought. For vendors whose software incorporates open-source components, demonstrating BSIMM-aligned supply chain practices addresses a primary concern of enterprise security teams.

‍

5) Measuring Improvement and Communicating to Stakeholders

BSIMM scorecards provide quantitative data that communicates security maturity to both internal stakeholders and external clients. Security leaders can demonstrate to executive management that security investments are yielding measurable improvements in maturity relative to industry benchmarks. Product leaders can understand how security practices impact development velocity and where investments in security automation will yield efficiency gains.

‍

For enterprise clients, BSIMM data provides transparency into your security program's trajectory. Rather than presenting security as a binary state—compliant or not compliant—BSIMM demonstrates that your organization treats software security as a continuous improvement discipline. This maturity in approach often matters as much to enterprise buyers as specific point-in-time capabilities.

‍

The roadmap derived from gap analysis shows clients your planned security improvements, demonstrating commitment to evolving security posture as threats change. This forward-looking perspective builds confidence that your organization will maintain appropriate security as your product and the threat landscape evolve.

‍

Key Benefits for Companies Selling to Enterprise Clients

BSIMM provides tangible advantages for B2B vendors navigating enterprise sales cycles and vendor security assessments:

‍

• Credible security differentiation: Rather than claiming "enterprise-grade security" without substance, BSIMM enables vendors to demonstrate specific, benchmarked security capabilities. This evidence-based approach resonates with technical decision-makers who evaluate vendor claims skeptically.

‍

• RFP competitive advantage: Enterprise RFPs increasingly include detailed security questionnaires probing specific practices. Organizations can reference BSIMM assessment results, cite specific implemented activities, and provide benchmarking context that demonstrates security maturity exceeding typical vendor responses.

‍

• Accelerated security reviews: Enterprise procurement processes include security reviews that can delay or derail deals. Organizations with documented BSIMM assessments can provide structured evidence of security practices, addressing reviewer questions with specificity that accelerates approval processes.

‍

• Alignment with client security frameworks: Enterprise clients using their own software security maturity models recognize BSIMM as an industry-standard framework. Vendors who speak the same language as client security teams demonstrate sophistication that builds trust and facilitates technical discussions.

‍

• Risk management transparency: Enterprise contracts increasingly include security requirements tied to risk management practices. BSIMM's Intelligence and Governance domains provide evidence that security decisions are informed by systematic risk analysis, not ad-hoc responses to incidents.

‍

• Continuous compliance support: While BSIMM itself is not a compliance framework, its practices directly support compliance requirements under ISO 27001, SOC 2, GDPR, and HIPAA. Organizations implementing BSIMM practices systematically address technical controls required by multiple frameworks, reducing duplicated effort and demonstrating comprehensive security approaches.

‍

Practical Steps to Implement BSIMM in Your Organization

‍

1) Initial Readiness and Scoping

Determine your current state before pursuing formal assessment. Do you have a software security group or function responsible for application security? Do security activities occur systematically across development teams, or are they ad-hoc responses to vulnerabilities? Have you established security requirements, standards, or training programs? Organizations without foundational security practices should establish basic capabilities before formal BSIMM assessment.

‍

Identify stakeholder buy-in across leadership, product, development, and security teams. BSIMM implementation requires cross-functional commitment—security cannot be imposed on development teams without product and engineering leadership support. Executive sponsorship is particularly critical for resource allocation and organizational priority.

‍

Scope your initial focus. Organizations with multiple product lines, diverse development methodologies, or distributed development teams may choose to baseline a subset of the organization initially, then expand BSIMM implementation as capabilities mature.

‍

2) Selecting Relevant Practices and Prioritizing

BSIMM is descriptive, not prescriptive—it documents current practices, not what a small group of experts think you should be doing. Not all organizations need to implement all 120+ activities immediately. Prioritize based on your risk profile, regulatory requirements, and enterprise client expectations.

‍

Use BSIMM benchmarking data to identify high-impact practices. Level 1 activities—those observed most frequently across organizations—represent foundational practices that most mature organizations implement. These typically provide the highest return on investment because they address the most common and significant risks.

‍

Align prioritization with client requirements. If enterprise clients consistently probe specific capabilities during security reviews—code review practices, penetration testing frequency, vulnerability remediation SLAs—prioritize BSIMM activities that demonstrate those capabilities.

‍

Consider quick wins that provide immediate value. Some BSIMM activities require significant organizational change and extended timeframes to implement. Others can be established relatively quickly and provide immediate security benefits and client communication value.

‍

3) Embedding into Software Development and Operations

Integrate security practices into existing workflows rather than creating parallel processes. Code review activities integrate with pull request workflows using automated static analysis tools and peer review processes. Security testing integrates into CI/CD pipelines using dynamic analysis, dependency scanning, and automated security test suites.

‍

Establish security metrics aligned with development processes: vulnerabilities identified per release, remediation time by severity level, security test coverage across codebases, training completion by role. These metrics track security outcomes without creating separate reporting structures.

‍

Implement security champion programs that distribute security expertise across development teams. Champions receive specialized security training, serve as security contacts within their teams, and help embed security practices into development workflows. This model scales security capabilities beyond centralized security teams.

‍

Automate where possible. Corporations are rapidly adopting automated security technology, enabling the "shift everywhere" security philosophy. Automated tools for static analysis, dependency scanning, secrets detection, and security testing reduce manual effort while improving consistency and coverage.

‍

4) Communicating Maturity to Enterprise Clients

Use BSIMM assessment results to demonstrate security maturity in client-facing materials: RFP responses, security documentation, vendor assessment questionnaires, and client presentations. Frame your security program in terms of the BSIMM structure: governance practices that establish strategy and accountability, intelligence practices that inform risk-based decisions, SSDL practices embedded throughout development, and deployment practices that ensure operational security.

‍

Create transparency around your security roadmap. Share gap analysis results with strategic clients, demonstrating where your current practices align with industry norms and where you're investing to exceed typical maturity. This forward-looking perspective demonstrates commitment to continuous improvement.

‍

Quantify your security capabilities using BSIMM metrics and benchmarking data. Rather than stating "we perform code reviews," specify "we perform automated static analysis and manual code review on 100% of releases, with findings tracked through documented remediation workflows—practices observed in fewer than 40% of organizations at our maturity level."

‍

Leverage assessment data in security incident communications. If vulnerabilities are discovered, demonstrate that your systematic approach to vulnerability management—evidenced through BSIMM practices—ensures consistent identification, assessment, and remediation processes.

‍

5) Monitoring, Measuring, and Improving

Establish periodic reassessment cycles—annually or biennially—to track progress. Longitudinal BSIMM data demonstrates improvement trajectories that matter more to enterprise clients than point-in-time snapshots. Organizations that show consistent maturity improvements signal commitment to security as an ongoing discipline.

‍

Use BSIMM benchmarking data to adjust priorities as the broader dataset evolves. As new practices become more commonly observed across organizations, consider whether they address risks relevant to your context. As threat landscapes change—supply chain attacks, AI-generated code, cloud-native vulnerabilities—BSIMM data reflects how mature organizations respond, informing your own evolution.

‍

Continuously align practices with emerging threats and technologies. BSIMM incorporates new activities as participating organizations adopt practices addressing current challenges. Recent iterations have added activities addressing SBOMs, supply chain risk, cloud security automation, and security champions—reflecting evolving industry practice.

‍

Common Challenges and How to Address Them

‍

1) Descriptive nature requires interpretation: Unlike other frameworks, BSIMM is descriptive, not prescriptive. The framework documents what organizations do, not what they must do. This requires interpretation to determine which practices apply to your context. Address this by using gap analysis relative to peer organizations and aligning prioritization with your specific risk profile and client requirements.

‍

2) Resource intensity: Implementing comprehensive software security practices requires investment in tools, personnel, and process changes. Organizations should prioritize activities based on risk and expected return rather than attempting comprehensive implementation immediately. Demonstrate ROI to executives by quantifying risk reduction, efficiency gains from automation, and competitive advantages in enterprise sales.

‍

3) Relevance for smaller organizations: A small organization is unlikely to be able to afford BSIMM, as formal assessments involve significant investment. Smaller organizations can still benefit from BSIMM by using the published framework as a reference model, self-assessing against BSIMM activities, and implementing prioritized practices without formal assessment. As the organization scales and pursues enterprise clients, formal assessment becomes justified by competitive advantage and client requirements.

‍

4) Alignment with other frameworks: Organizations often implement multiple frameworks simultaneously—ISO 27001 for information security management, SOC 2 for service organization controls, BSIMM for software security maturity. Avoid duplicated effort by mapping BSIMM practices to controls required by other frameworks, using BSIMM implementation to satisfy multiple requirements simultaneously, and establishing unified evidence collection processes.

‍

5) Keeping practices current: Threats evolve, technologies change, and security practices must adapt. Address this through periodic reassessment that incorporates updated BSIMM activities, monitoring threat intelligence to identify emerging risks not yet addressed by existing practices, and participating in security communities to learn how peer organizations adapt to new challenges.

‍

Use Scenario: SaaS Vendor Selling to Financial Services

Consider a software-as-a-service vendor providing analytics tools to financial institutions. Enterprise clients conduct rigorous vendor security assessments, probing software development practices, data protection controls, and incident response capabilities. Initial security questionnaires reveal gaps in the vendor's ability to demonstrate systematic security practices beyond basic compliance certifications.

‍

The organization conducts a BSIMM assessment, establishing a baseline that reveals gaps in architecture analysis, inconsistent code review practices, limited security testing automation, and absence of formal security training for developers. The assessment also identifies strengths: established vulnerability management processes and comprehensive penetration testing.

‍

Based on gap analysis and client feedback, the organization prioritizes implementing architecture analysis for new features, establishing automated code review integrated into CI/CD pipelines, creating a security champion program across development teams, and implementing developer security training. Over 12 months, these practices become embedded into development workflows.

‍

The next BSIMM assessment demonstrates measurable improvement across SSDL Touchpoints and Governance practices. The organization uses these results in subsequent RFPs, providing specific evidence of software security maturity: "We perform architecture security review on 100% of new features, automated and manual code review on all releases, and maintain security champion coverage across all product teams—practices that benchmark in the top quartile of financial services software vendors."

‍

This concrete demonstration of security maturity differentiates the vendor from competitors offering generic compliance statements. The systematic approach to software security—documented through BSIMM—provides the evidence-based assurance enterprise financial clients require, accelerating security reviews and reducing friction in procurement processes.

‍

Conclusion

The BSIMM framework is a data-driven approach for measuring and communicating software security maturity, grounded in observed practices of mature organizations, unlike prescriptive models. For B2B vendors, it helps demonstrate systematic security capabilities embedded in the SDLC, satisfying enterprise clients' rigorous vendor assessments and data protection requirements beyond point-in-time compliance certifications. Organizations should use BSIMM as a measurement tool for continuous improvement: baseline the current initiative, identify peer-relative gaps, prioritize based on risk and client needs, and implement systematically. The value is establishing approaches that reduce risk and support data protection, making compliance a natural outcome, not manufactured evidence. Integrate BSIMM if serving enterprise clients demanding security maturity evidence beyond basic compliance.

‍

Frequently Asked Questions

1) What is the difference between BSIMM and SAMM?

Both BSIMM and OWASP SAMM share common history, conceived around 2008-2009, but have evolved independently with distinct conceptual differences. BSIMM is descriptive and empirical—it documents what organizations actually do based on assessment data from participating firms. BSIMM is proprietary and only Synopsys can conduct real assessments, whereas SAMM is open source. SAMM is prescriptive, providing a structured roadmap of practices organizations should implement to improve security maturity. BSIMM provides benchmarking against industry peers; SAMM provides a maturity progression framework. Organizations may use both: SAMM to guide improvement roadmaps, BSIMM to benchmark progress against industry data.

‍

2) What is the BSIMM scorecard?

The BSIMM scorecard is the measurement output from a BSIMM assessment. It documents which of the 120+ BSIMM activities your organization currently performs, organized by the 12 practices across four domains. The scorecard shows your maturity level within each practice, typically represented by which activity levels (1-3) you've implemented. Critically, the scorecard includes benchmarking data comparing your activity profile to peer organizations—by industry vertical, organization size, or the entire dataset. This comparison identifies gaps where peer organizations have implemented practices you have not, and strengths where you exceed typical maturity. Organizations use scorecards to communicate security posture to stakeholders, prioritize improvement efforts, and demonstrate progress through longitudinal comparison of periodic assessments.

‍

3) What is Building Security In Maturity Model (BSIMM)?

Building Security In Maturity Model (BSIMM) is the full name for the framework commonly referenced by its acronym. The name reflects the framework's purpose: measuring how organizations build security into software through systematic practices rather than addressing security as an afterthought. "Maturity model" indicates that BSIMM tracks progressive sophistication in software security capabilities—organizations advance from foundational practices to more sophisticated approaches as their programs mature. The framework measures software security initiative maturity specifically, focusing on practices throughout the software development lifecycle rather than broader information security controls. BSIMM enables organizations to assess their current state, benchmark against industry peers, identify improvement priorities, and demonstrate security maturity to stakeholders including enterprise clients, regulators, and internal executives.

‍

4) Who created BSIMM?

BSIMM was created through collaboration between Cigital (founded by Gary McGraw) and Fortify Software (founded by Brian Chess). The initial release in 2009 emerged from empirical research documenting software security practices across nine participating firms. Gary McGraw and Sammy Migues led the development effort, establishing the data-driven methodology that distinguishes BSIMM from prescriptive frameworks. The framework built on earlier work including OpenSAMM, created by Pravir Chandra with funding from Fortify. Following industry consolidation, Synopsys (which acquired both Cigital and Fortify Software's parent company) now manages BSIMM. Synopsys conducts BSIMM assessments, maintains the dataset, and publishes annual updates incorporating data from participating organizations—currently over 120 firms across multiple industry verticals.