Secure-development governance
Do we build our software under a controlled secure-development model?
Software is where an organization builds its own risk: insecure code, an insecure delivery pipeline, defects merged without review, and unvetted open-source or AI-suggested dependencies all enter through development. The governing body's question is not whether software ships, but whether it can require, and see in evidence, that software is designed, coded, reviewed, tested, and its dependencies vetted under a controlled model.
Note
Adopting a page here decides nothing for you. The leadership pages linked here are explanatory and advisory; they establish no requirement and prove nothing about your organization. Every claim in them resolves to the governing reference documents in the corpus, and it is those documents that govern.
Leadership
The leadership pages
Pages from the executive layer mapped to this concern, generated from the narrative registry. They explain and advise; the documents below govern.
- What the governing body should require for secure-development governance oversightexecutive brief
- What the governing body should ask about the organization's secure-development model, code review, dependencies, pipelines, and release qualityoversight question set
- When an AI-suggested dependency turns out to be a malicious packagescenario
Documents
The governing documents
The evidence shelf: the corpus documents the pages above resolve to, joined to the library's registries at build time. These are the documents that govern, and the evidence to ask for starts here.
- Secure Development and Engineering Policypolicy, Dev security
- Developer Security Requirementsstandard, Dev security
- DevOps Security Requirementsstandard, Dev security
- Quality Assurance and Testing Standardstandard, Dev security
- Software Composition Analysis Standardstandard, Dev security
- Software Evaluation, Acceptance and Lifecycle Management Standardstandard, Dev security
- Secure Code Review Procedureprocedure, Dev security
- AI Coding Assistant Security Guidelineguideline, Dev security
- Compliance Controls and Gap Register Templateregister, Dev security
Frameworks
Frameworks touched
The external frameworks the shelf above maps, from the corpus registry. The documents' framework spellings are normalized against the crosswalk's committed alias maps: every spelling that names a crosswalk instrument, whole or by a clause, appears once as the instrument's short label and links its instrument page; a cited text that names no instrument is shown as plain text.
- Canada CCCS Baseline Cyber Security Controls for Small and Medium Organizations (held edition: V1.2, February 2020)
- CIS CSC v8.1
- COBIT
- CSA AICM
- CSA CCM
- CycloneDX / SPDX
- EU AI Act
- EU Cyber Resilience Act
- ISO 9001:2015
- ISO/IEC 25010
- ISO/IEC 27001
- ISO/IEC 27002
- ISO/IEC 27034 (all parts)
- ISO/IEC 42001
- ISO/IEC/IEEE 12207:2026
- NIST CSF
- NIST SP 800-218 Version 1.1
- NIST SP 800-53
- NIST SSDF
- OpenSSF Best Practices
- OWASP ASVS 5.0.0
- OWASP ASVS v5
- OWASP Dependency-Check
- OWASP SAMM
- OWASP Top 10:2025
- OWASP WSTG v4.2 (Web Security Testing Guide)
- SLSA v1.2
- SLSA v1.2 Build
- SLSA v1.2 Framework
- Treasury Board of Canada Directive on Security Management (held edition: takes effect July 1, 2019), Appendix B (mandatory procedures for information technology security control)
- Treasury Board of Canada Secretariat Security Playbook for Information System Solutions (held page: date modified 2025-10-22)
- US Executive Order 14028
Go deeper