EDUCATION, SECURE, DEVELOPMENT

🔐 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

Cost of filling the gap by life-cycle stages Stab diagram - the later stage (requirements → Design → Development → Testing → Production) finds a shortage, the higher the relative elimination costs. Safety built-in, not glued The later the lack is found, the more expensive it is to overcome (relative costs, illustrative) Shift-left: Find and prevent as early as possible ×1 Requirements ×5 Design ×10 Development ×15 Testing ×30+ Production CISA Secure by Design (2023), NIST SSDF SP 800-218, Saltzer & Schroeder principi

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.

In practice

Safety is a business requirement, not an additional function. Key principles: minimum attack surface, minimum privileges, multilayer protection, safe secure failure (fail safely) and safe defaults.

Reference

Principles of safety design for CISA "Secure by Design" (2023), NIST SSDF (SP 800-218), OWASP, Saltzer & Schroeder (1975).

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

Safe development life cycle phases Six phases with built-in safety performance - requirements, design, development, testing, placement, maintenance. Safe development life cycle Safety is not a separate stage at the end - it runs through the whole cycle Requirements Safety requirements - Abuse - Compliance requirements 2. Design - Crisis Modelling (STRIDE) - Security architecture - Analysis of the attack surface 3. Development - Safe code + code overview - SAST (static analysis) - SCA (dependency check) Testing - DAST (dynamic analysis) - Intrusion test - Fuzzing 5. Deployment - Safe configuration - Mystery Management - SBOM + signature 6. Maintenance - Patch management - Monitoring and magazines - Incident response Cycle recurs - lessons from maintenance become new requirements Microsoft SDL, NIST SSDF SP 800-218, OWASP SAMM, BSIMM, ISO/IEC 27034

In practice

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

OWASP Top 10 Risks and Protection Table with the most common risks of web applications on the left and corresponding secure encoding protection on the right. Risk → Protection Safe code prevents the most common weaknesses already in writing RISK (OWASP Top 10) PROTECTION Defective access control Authorization on the server side for each request Cryptography errors TLS 1.3. tested cryptography Injection (SQL/command) Parameterd queries, input validation, output encoding Insafe design Danger modelling, safety requirements in the project Insecure configuration Safe defaults, hardening, minimal surface Obsolete components SCA, regular updating of addiction Authentication errors MFA, secure session management, rate-limit Data integrity errors Signed artefacts, reliable sources of addiction Insufficient log Recording and warning of security events OWASP Top 10:2021, OWASP ASVS, OWASP Cheat Sheets, CWE Top 25, SEI CERT

In practice

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) 5.0 (2025), 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

CI/CD conveyor with safety gates Six stages of the conveyor from pre-commit to execution time, each with an automated safety gate; the Shift-left arrow indicates security as early as possible. CI/CD conveyor with safety gates Each goal automated and blocking - safety independent of human memory Shift-left: security as early as possible Pre-commit Committee / PR Construction Test Deployment Time secrecy scanning lint SAST, SCA code statement SBOM signature DAST, IAST integration tests IaC scan config audit monitoring WAF / RASP Gate that fails → conveyer stops (build file) OWASP Top 10 CI/CD Security Risks, NIST SSDF, SLSA, DevSecOps prakse

Change in conveyor step by step

Where automatic gates can stop the change. Green note shows when the gate stops it.

One change in production

  1. 1
    DeveloperBefore commit: mystery scanning locally

    The key that goes into git history must be changed - deletion from history does not help.

  2. 2
    Developer → CIpull request

    Gates are stopped if: a secret found in the code or a critical error found in SAST

    Conveyer starts automatic checks. If the gate falls, no change is made.

  3. 3
    CISAST code, SCA dependence, second person reviews

    Tools find certain samples, man - logic errors that the tools do not see.

  4. 4
    CIBuilds image → scans → SBOM → signs

    SBOM is a list of ingredients. The signature proves that the image comes directly from this conveyor.

  5. 5
    CI → Environmentsigned image + SBOM

    The gate is stopped if: signature does not match or the image has critical vulnerability

    The environment only accepts signed images - a hand-made image is not launched.

  6. 6
    EnvironmentDAST in test environment: Checks the work app from the outside

    Finds what is only seen in operation: configuration, headers, authentication.

  7. 7
    EnvironmentRelease into production with possibility to return to previous version

    If something goes wrong, return is one step, no new building.

  8. 8
    NoteThe conveyor itself is aimed at: minimal rights, secrets outside the code, verified third party activities

    That takes over the conveyor, it can deliver its code to all users.

In practice

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 construction, to limit the authorisation and verification of the work of the conveyor (GitHub Actions etc.) so that the conveyor cannot compromise.

Automated safety testing

SAST, SCA, DAST, IAST - who finds anything

Comparison of safety testing methods Six automated safety testing methods with what each analyzes and when it works in the conveyor. Comparison of the test method No method alone finds everything - they complement each other SAST Static source analysis When: committee / construction White box Many false-positive SCA Dependence and Libraries When: committee / construction Known CVE + licences Based on SBOM Secret Scanning The Secrets of Code and History When: Pre-commit API keys, passwords Prevents leak in git history DAST Operating apps When: test / staging Black box Performance time weakness IAST Instrumented execution time When: functional tests Grey box More precisely, less false Container / IaC Images + Infrastructure code When: construction / placement Insecure images, config CIS benchmarks OWASP, NIST SSDF SP 800-218 (RV group), fuzzing (OSS-Fuzz) complements dynamic testing

In practice

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 by a manual review and intrusion test.

Software supply chain integrity

SBOM, signature and SLSA levels

Supply chain integrity controls and SLSA levels Upper supply chain flow from source to placement with integrity control in each step; below which SLSA construction levels from L0 to L3. Supply chain: integrity from source to deployment Prove what you're launching and where it comes from Source version control 2-person overview Building (building) isolated, repeatable origin (provenance) Artefact SBOM (CycloneDX/SPDX) signature (Sigstore) Deployment verify signature check the origin SLSA construction levels - increasing integrity L0 No guarantees no origin marking baseline L1 Origin available and documented automatic construction L2 Signed origin managed construction platform harder to fake L3 Uncounterfeitable insulation highest guarantee SLSA v1.0, NIST SSDF SP 800-218, US EO 14028, EU CRA, in-toto attestations SBOM = ingredients, origin (provenance) = how it was built, signature = which released it

In practice

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-tototo, US EO 14028, EU Cyber Resilience Act (Regulation (EU) 2024/2847): reporting on active use of injuries from 11 September 2026, full requirements from 11 December 2027.

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 is 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
Threatened Modeling 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 note - how and from which the artefact was built (SLSA).
artefakts
Final result of the construction - executable, package or container image.
build
Construction - conversion of source to a launchable artefact.