BSIMM

Config & Vulnerability Management. An incident response capability is created or used so software security incidents are handled and fed back to development.

• Software incident response procedure and records
• Feedback of incidents to development

• No software IR capability
• Incidents not fed back to development

Config & Vulnerability Management. Software defects found in operations monitoring are identified and fed back to development so they are fixed at the source.

• Process feeding ops-discovered defects to development
• Tracking of fed-back defects to closure

• Ops defects not fed back
• No closure tracking

Config & Vulnerability Management. Software bugs found in operations are tracked through the fix process so vulnerabilities are remediated and verified.

• Vulnerability tracking from discovery to fix and verification
• Remediation SLAs

• Vulnerabilities not tracked to closure
• No remediation SLAs

Config & Vulnerability Management. A bug bounty program is operated so external researchers can responsibly report vulnerabilities.

• Bug bounty/vulnerability disclosure program and policy
• Records of submissions and remediation

• No vulnerability disclosure/bug bounty
• Submissions not remediated

Penetration Testing. External penetration testers are used so an independent assessment finds vulnerabilities before attackers do.

• Penetration test scope and reports
• Remediation tracking of findings

• No penetration testing
• Findings not remediated

Penetration Testing. Penetration test results are fed into defect management so findings are tracked and fixed like other defects.

• Pen-test findings logged in the defect/tracking system
• Closure tracking and retest

• Findings not tracked
• No retest of fixes

Penetration Testing. Penetration testing tools are used internally so testing scales beyond periodic external engagements.

• Internal pen-testing toolset and usage
• Findings and remediation

• No internal pen-test tooling
• Limited testing cadence

Software Environment. Basic host and network security (hardening, patching) is ensured so the software's operating environment is defensible.

• Host/network hardening baselines
• Patch management for the environment

• No hardening baselines
• Environment unpatched

Software Environment. Cloud security controls are implemented so cloud-hosted applications inherit a secure configuration baseline.

• Cloud security baseline/controls (CSPM, IAM, network)
• Monitoring of cloud configuration

• No cloud security baseline
• Cloud misconfiguration unmonitored

Software Environment. The application inventory is enhanced with an operations bill of materials (SBOM/OBOM) so deployed components and dependencies are known.

• Software/operations bill of materials for deployed apps
• Use of the BOM for vulnerability response

• No SBOM/OBOM
• Deployed components unknown

Compliance & Policy. The organisation unifies regulatory pressures into a single view so software security requirements address all applicable obligations.

• Consolidated register of regulatory/compliance obligations affecting software
• Mapping of obligations to software security requirements

• Obligations not consolidated
• Requirements not mapped to obligations

Compliance & Policy. Privacy obligations and the personal data (PII) handled by software are identified so privacy requirements are built in.

• Identification of PII handled by applications
• Privacy obligations mapped to software requirements

• PII not identified
• Privacy obligations not addressed in software

Compliance & Policy. A software security policy is created to satisfy regulatory and customer-driven security requirements and to govern the SSDL.

• Documented software security policy
• Communication and enforcement of the policy

• No software security policy
• Policy not enforced

Strategy & Metrics. The organisation publishes its software security process and evolves it as necessary, so roles, activities and deliverables are defined and improved over time.

• Published software security process/SSDL document
• Evidence of periodic review and evolution
• Defined roles, activities and deliverables

• No documented software security process
• Process not reviewed/evolved
• Roles undefined

Strategy & Metrics. Executives are educated on software security so they understand the risk and support the initiative with sponsorship and resources.

• Executive briefing/training materials and attendance
• Evidence of executive sponsorship and resourcing

• Executives not engaged
• No sponsorship/resources

Strategy & Metrics. Security checkpoints and governance gates are implemented in the SDLC so releases require security sign-off.

• Defined security checkpoints/gates in the SDLC
• Records of security sign-off prior to release

• No security gates
• Releases without security sign-off

Strategy & Metrics. Security gates are enforced with measurements and exceptions are tracked, so risk decisions are explicit and accountable.

• Gate enforcement records and metrics
• Exception register with approvals and expiry

• Gates not enforced
• Exceptions untracked

Training. Software security awareness training is conducted so developers and stakeholders understand secure development expectations.

• Awareness training programme and completion records
• Coverage of developers and relevant roles

• No awareness training
• Coverage incomplete

Training. On-demand individual software security training is delivered so staff can access targeted learning when needed.

• On-demand training catalogue and usage records
• Role-targeted training availability

• No on-demand training
• Training not role-targeted

Attack Models. A data classification scheme and inventory are created so the most important data and systems can be protected appropriately.

• Data classification scheme and inventory of sensitive data
• Prioritisation of applications by data sensitivity

• No data classification
• Sensitive data not inventoried

Attack Models. Potential attackers and their motivations are identified so threats can be modelled realistically.

• Documented threat actors/personas relevant to the applications
• Use of attacker profiles in threat modelling

• Attackers not identified
• Threat modelling not attacker-informed

Attack Models. Attack intelligence is gathered and used so the organisation stays current on relevant threats and techniques.

• Attack-intelligence sources and feeds
• Evidence intelligence informs design/testing

• No attack intelligence
• Intelligence not used

Security Features & Design. Common security features (authentication, authorisation, logging, crypto) are built and published for reuse so teams do not reinvent them insecurely.

• Catalogue of published, reusable security features
• Adoption of the features by development teams

• No reusable security features
• Teams reimplement security primitives

Security Features & Design. Security engages with application architecture teams so secure design is considered from the start.

• Records of security engagement in architecture/design
• Secure-design guidance provided to architects

• Security not engaged in design
• No secure-design guidance

Standards & Requirements. Security standards are created so teams have clear, consistent requirements to build to.

• Documented security standards (coding, crypto, auth)
• Communication and adoption of standards

• No security standards
• Standards not adopted

Standards & Requirements. Compliance constraints are translated into concrete software security requirements so obligations are actionable for developers.

• Mapping of compliance constraints to software requirements
• Traceability from obligation to requirement

• Compliance not translated to requirements
• No traceability

Standards & Requirements. Open source components are identified and their risk managed so known-vulnerable or non-compliant components are controlled.

• Software composition analysis (SCA) inventory of open source
• Open-source policy and risk handling

• Open source not inventoried
• No SCA/open-source policy

Architecture Analysis. A security feature review is performed so the design's security mechanisms are assessed against requirements.

• Security feature review records
• Findings tracked to remediation

• No security feature review
• Findings not remediated

Architecture Analysis. A risk-ranking methodology is used to prioritise applications for architecture analysis so effort focuses on the highest-risk systems.

• Documented application risk-ranking methodology
• Prioritised list of applications for analysis

• No risk ranking
• Analysis effort not prioritised

Architecture Analysis. Threat modelling/architecture analysis using STRIDE or an equivalent method is performed so design-level risks are identified.

• Threat models / architecture-analysis records (STRIDE or equivalent)
• Identified threats and mitigations

• No threat modelling
• Design risks not identified

Code Review. Opportunistic code review is performed so security defects are found during development.

• Code review records covering security
• Findings tracked to fix

• No code review
• Security not covered in review

Code Review. Automated code review tools (static analysis) are used so security defects are detected at scale.

• SAST tool deployment and scan results
• Triage and remediation of findings

• No SAST
• Findings not triaged/remediated

Code Review. Code review is made mandatory for all projects so coverage is consistent.

• Policy mandating code review for all projects
• Coverage metrics across the portfolio

• Code review optional
• Coverage gaps

Security Testing. Edge and boundary value condition testing is performed so security-relevant input handling is exercised.

• Test cases covering edge/boundary conditions
• Security test results

• No boundary/security test cases
• Results not acted on

Security Testing. Tests are driven by security requirements and features so testing verifies the controls that matter.

• Security test cases traceable to requirements/features
• Coverage of security requirements in testing

• Tests not requirements-driven
• Security requirements untested

Security Testing. Security testing tools (DAST/IAST) are integrated into the pipeline so applications are tested as they are built.

• DAST/IAST integration in CI/CD
• Test results and remediation

• No dynamic security testing
• Testing not integrated into the pipeline