🔐 Safe software development
Six topics on how to develop secure software - from Secure by Design principles to CI/CD security gates and supply chain integrity - by international practice (CISA, NIST SSDF, OWASP, SLSA). Examples are general, intended for training.
Safety as design requirement
Secure by Design and Secure by Default
Secure by Design means security as a requirement from day one; Secure by Default means secure defaults (e.g. MFA enabled, ports closed) so that the user does not have to activate anything manually.
Application
Safety is a business requirement, not an additional function. Key principles: minimum attack surface, minimum privileges, protection at depth, secure failure (fail safely) and safe defaults.
Reference
CISA "Secure by Design" (2023) · NIST SSDF (SP 800-218) · OWASP · Saltzer & Schroeder (1975) safety design principles.
Safety Note
The responsibility for safety belongs to the manufacturer and not to the user. The safety to be manually activated in practice remains excluded - therefore the default must be safe.
Safe Development Life Cycle (SDLC)
Safety performance in each phase
Application
For each phase your security action and responsible. Map on recognised frameworks - Microsoft SDL, NIST SSDF practices (PO, PS, PW, RV) and OWASP SAMM mature domains.
Reference
NIST SSDF SP 800-218 · Microsoft Security Development Lifecycle · OWASP SAMM · BSIMM · ISO/IEC 27034 (application security).
Safety Note
Danger modelling during the design phase finds architectural flaws that no code scanner sees - they are most expensive to repair later.
Safe coding practices
The most common risks (OWASP Top 10) and protection
Application
Practical checklist for the developer and code review. OWASP USS gives verifiable requirements at three levels (L1-L3) depending on the application's decline.
Reference
OWASP Top 10:2021 · OWASP Application Security Verification Standard (USAS) · OWASP Cheat Sheet Series · CWE Top 25 · SEI CERT Coding Standards.
Safety Note
Never trust the input and write your own cryptography. Valide input to server (not only browser) and uses proven libraries.
DevSecOps - Safety on conveyor
Automated safety gates at each stage
Application
Each security tool becomes an automatic conveyor gate. Its security is scaled up by design rather than relying on manual testing under time pressure.
Reference
OWASP Top 10 CI/CD Security Risks · NIST SSDF SP 800-218 · SLSA · DevSecOps (culture + automation).
Safety Note
The conveyor itself is the goal - to protect the secrets of the building, to limit employee permits and to check third party activities (GitHub Actions etc.) so that the conveyor is not compromised.
Automated safety testing
SAST, SCA, DAST, IAST - who finds anything
Application
Combine methods according to conveyor section: static (SAST/SCA/secret) early, dynamic (DAST/IAST) tests, infrastructure scanning before deployment.
Reference
OWASP (test tools - ZAP, Dependency-Check) · NIST SSDF SP 800-218 · CIS Benchmarks · OSS-Fuzz (continuous fuzzing).
Safety Note
Tools find known templates, not business logic errors. Automated testing does not check whether access control is logically correct - it is found in a manual review and penetration test.
Software supply chain integrity
SBOM, signature and SLSA levels
Application
SBOM allows a quick answer "do we are affected by this CVE?"; origin (provenance) and signature proves that the artefact (the final file of the building) comes from a reliable, genuine construction process. Together they protect the supply chain.
Reference
SLSA v1.0 · NIST SSDF SP 800-218 · SPDX / CycloneDX (SBOM formats) · Sigstore/cosign · in-toto · US EO 14028 · EU Cyber Resilience Act (CRA).
Safety Note
Most code is third party addiction. SolarWinds and similar incidents show - compromised construction or addiction to circumvent all other protections. Verify before launch.
Abbreviations
All abbreviations used in the guide (original and meaning).
- SDLC
- Software Development Life Cycle - software development life cycle.
- SSDLC
- Safe SDLC - life cycle with built-in safety.
- SDL
- Security Development Lifecycle - Microsoft secure development process.
- SSDF
- Secure Software Development Framework - NIST SP 800-218.
- SAMM
- Software Assurance Integrity Model - OWASP maturity model.
- BSIMM
- Building Security In Matrity Model - real practice measurement.
- SAST
- Static Application Security Testing - Statistical Source Analysis.
- DAST
- Dynamic Application Security Testing - Test of the running application.
- IAST
- Interactive Application Security Testing - instrumented performance test.
- SCA
- Software Composition Analysis - addiction/component analysis.
- RASP
- Runtime Application Self-Protection - self-defence of execution time.
- WAF
- Web Application Firewall for web applications.
- DevSecOps
- security embedded in DevOps culture and automation.
- CI/CD
- continuous integration/delivery (conveyor).
- IaC
- Infrastructure as Code - infrastructure as code.
- SBOM
- Software Bill of Materials - a list of software components.
- SLSA
- Supply-chain Levels for Software Artifacts - supply chain levels.
- CWE
- Common Weakness Enumeration - software weakness classification.
- CVE
- Common Vulnerabilities and Exposures - a public vulnerability register.
- ASVS
- OWASP Application Security Verification Standard.
- STRIDE
- threat modelling categories (Microsoft).
- MFA
- Multi-Factor Authentication - Multifactor Authentication.
- TLS
- Transport Layer Security - transport layer encryption.
- CRA
- EU Cyber Resilience Act - EU cyber resilience regulation.
- provenance
- origin record - how and from which the artefact was built (SLSA).
- artefakts
- the final result of the construction - executable, package or container image.
- build
- construction - conversion of source to a launchable artefact.