BSIMM Software Security Maturity Assessment
This assessment applies the Building Security In Maturity Model (BSIMM) to a fictional university that recently had an application security incident. It maps current development practices to the four BSIMM domains, finds early-stage maturity where application security is informal and reactive, and recommends a phased path that starts with governance, training, and secure SDLC integration.
By Sean Richard · Project date February 2026
At a glance
- Scenario
- A fictional university (course scenario) that recently suffered an application security incident and needs to understand its software security posture.
- Method
- Map current development practices to the four BSIMM domains and their practices: current state, BSIMM alignment, recommendation.
- Finding
- Early-stage maturity: compliance and development processes exist, but application security is informal and reactive.
- Outcome
- A phased path focused first on governance, training, and secure SDLC integration.
What BSIMM is and why it fit this case
BSIMM is a descriptive maturity model based on real-world observations from hundreds of organizations, used to measure and guide software security initiatives. It has four domains, each containing practices with observable activities: Governance, Intelligence, SSDL Touchpoints, and Deployment. Because it describes what organizations actually do, it suits an organization that needs to find out where it stands before deciding what to fix. Each practice in the assessment is handled the same way: the current state, how that aligns to BSIMM, and a recommendation.
Findings across the four BSIMM domains
| Domain and practice | Current state | Recommendation |
|---|---|---|
| Governance: Strategy and Metrics | No formal application security strategy, executive sponsorship, metrics, or security objectives. Delivery deadlines come first. | A leadership-backed strategy with measurable goals, and a security champion or small AppSec group reporting progress. |
| Governance: Compliance and Policy | FERPA and GLBA compliance focuses on data handling and infrastructure, not application-level security. | Map compliance requirements to application security controls, and enforce policies through reviews and tooling. |
| Governance: Training | No structured secure coding training. Security knowledge is informal and inconsistent. | Role-based training for developers, testers, and architects, reinforced with refreshers or hands-on exercises. |
| Intelligence: Attack Models | No structured threat modeling, attack surface analysis, or attacker personas. | Introduce threat modeling early in design, using a framework such as STRIDE. |
| Intelligence: Security Features and Design | Authentication, authorization, and input validation are implemented inconsistently. | Standard security design patterns and reusable components, with security reviews at architecture and design. |
| SSDL Touchpoints: Architecture Analysis | Reviews focus on functionality and performance, with little emphasis on security risk. | Security architecture reviews that assess trust boundaries, data flows, and attack vectors before implementation. |
| SSDL Touchpoints: Code Review | Reviews cover correctness and style. No security checklist or tooling. | Secure code review checklists, developer training, and automated static analysis. |
| SSDL Touchpoints: Security Testing | Testing is functional. Vulnerabilities are often found after deployment. | Static analysis, dynamic testing, and vulnerability scanning before release, with security defects tracked alongside functional bugs. |
| Deployment: Penetration Testing | Not performed regularly, and typically reactive after incidents. | Regular penetration testing of high-risk applications, with findings fed back into development and training. |
| Deployment: Configuration and Vulnerability Management | Limited visibility into post-deployment vulnerabilities, and inconsistent patching. | Centralized vulnerability tracking, clear remediation processes, and standardized monitoring and patch management. |
The pattern behind the findings
Every domain shows the same shape. Processes exist, such as code reviews, architecture reviews, testing, and regulatory compliance, but none of them looks at security. Code review checks correctness and style. Architecture review checks functionality and performance. Testing checks features. The organization is not starting from nothing: the checkpoints are already there, and most recommendations add a security lens to a process that already runs.
The second pattern is that security activity is reactive. Penetration testing happens after incidents, design decisions account for security risk late or after something goes wrong, and vulnerabilities are found after deployment. The recommendations for threat modeling in the design phase and security testing before release move that work earlier in the life cycle.
Recommended sequence
The assessment concludes that a phased approach focusing first on governance, training, and secure SDLC integration provides the strongest foundation. Governance supplies measurable goals and a security champion or small application security group to guide the effort. Training gives developers, testers, and architects the ability to recognize common vulnerabilities, which the code review and testing recommendations depend on. Penetration testing and centralized vulnerability management then feed findings back into development and training.
What this project demonstrates
- Assessing software security maturity against all four BSIMM domains.
- Documenting current state, framework alignment, and a recommendation for each practice.
- Recognizing that existing review and test processes can carry security checks.
- Sequencing improvements: governance and training before tooling and testing.
Read the full document
Portfolio edition of coursework completed for the B.S. in Cyber/Computer Forensics & Counterterrorism at Full Sail University. The organization and scenario are a course case study, and this page summarizes the full document.