Secure Development Policy: Secure Development Lifecycle

Why software development needs a security policy

Software is everywhere. Whether your organization develops its own applications, makes custom modifications to standard software, or commissions external developers — somewhere in the organization, code is being written, and that code can contain vulnerabilities.

The reality in many organizations looks like this: developers write code to the best of their knowledge, security is recognized as a topic but not systematically addressed. Penetration tests happen but only shortly before go-live, when changes are expensive and time-consuming. Third-party libraries are integrated without checking their security status. Development environments have access to production data because it is more convenient.

A secure development policy addresses exactly this. It defines binding rules for the entire development lifecycle and ensures that security is not left to chance, individual developer competence, or the time pressure before a release.

What the standards require

ISO 27001

ISO 27001 Annex A contains several controls that directly target software development:

A.8.25 Secure Development Life Cycle: Rules for the secure development of software and systems must be established and applied. This is the core of the policy.

A.8.26 Application Security Requirements: Security requirements must be identified, specified, and approved when developing or acquiring applications.

A.8.27 Secure System Architecture and Engineering Principles: Principles for secure system architecture must be documented and applied.

A.8.28 Secure Coding: Secure coding practices must be applied to software development. This includes coding standards, code reviews, and automated security checks.

Additionally relevant: A.8.8 Management of Technical Vulnerabilities (vulnerability management) and A.8.9 Configuration Management (secure configuration of development environments).

NIS2

NIS2 Article 21 Paragraph 2 No. 5 requires "security measures in the acquisition, development, and maintenance of network and information systems, including vulnerability management and disclosure." This applies not only to software companies but to every organization that develops or customizes software.

Scope of the policy

The policy must clearly define what it applies to. Typically, the scope includes:

• In-house development (web applications, internal tools, APIs, scripts)
• Custom modifications to standard software (customizing, plugins, extensions)
• Commissioned development by external service providers
• Configuration and deployment of software
• Infrastructure as Code development (IaC, Terraform, Ansible)

Typically out of scope are pure Office macros and simple automations, unless they process sensitive data. The policy should define a threshold above which a development activity falls under the policy.

Security by design: Security from the start

The core principle of the policy is security by design. This means that security requirements are not checked at the end of the development process but defined at the beginning.

Requirements phase

Every development project starts with defining requirements, and security requirements are part of them. The policy requires that a security assessment of the requirements takes place for every project:

• What data does the application process, and how is it classified?
• What authentication and authorization mechanisms are needed?
• What encryption requirements exist (transport, storage)?
• What compliance requirements apply (DSGVO/GDPR, industry-specific regulations)?
• What interfaces exist to other systems, and how are they secured? Guidance on API security helps with securing external interfaces.

The results are documented as security requirements and incorporated into the specification. For projects with high protection requirements, the policy recommends threat modeling that systematically identifies potential threats and defines countermeasures.

Architecture and design

The policy defines architecture principles that must be followed in system development:

Least privilege: Every component, every service, and every user receives only the minimum necessary permissions.

Defense in depth: Security is implemented in multiple layers, not relying on a single measure.

Fail secure: In case of failure, the system falls into a secure state, not an open one.

Separation of concerns: Security-critical functions (authentication, authorization, cryptography) are implemented as standalone modules, not scattered across the application.

Minimal attack surface: Only the necessary functions, ports, and interfaces are exposed. Everything else remains closed.

Secure coding guidelines

The policy references or contains secure coding guidelines that are binding for all developers. These guidelines are based on established standards such as the OWASP Top 10, the OWASP Application Security Verification Standard (ASVS), and the CWE Top 25.

Core secure coding rules

Input validation: All external inputs are validated, filtered, and sanitized. Trust no input that comes from outside, regardless of whether it originates from a user form, an API, a file, or a database.

Output encoding: All outputs are context-appropriately encoded to prevent injection attacks (XSS, SQL injection, command injection).

Authentication and session management: Use proven authentication libraries, not custom implementations. Sessions must be managed server-side, tokens must be cryptographically securely generated, and session fixation must be prevented.

Authorization: Permission checks are performed server-side on every access, not only in the frontend. IDOR vulnerabilities (Insecure Direct Object Reference) are prevented through consistent authorization checks.

Cryptography: Use exclusively established, current algorithms and libraries. Never implement custom cryptographic methods. Keys are securely generated, stored, and rotated.

Error handling and logging: Error messages to users contain no technical details that could be useful to an attacker (stack traces, database queries, internal paths). Security-relevant events are logged: failed authentications, authorization violations, input validation errors.

Secrets management: Credentials, API keys, certificates, and other secrets do not belong in source code, configuration files in the repository, or container images. The policy references a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.).

Security in the CI/CD pipeline

Modern software development uses automated build and deployment pipelines (CI/CD). The policy must define which security checks are integrated into this pipeline.

Static Application Security Testing (SAST)

SAST tools analyze source code for known vulnerability patterns without executing the application. They find SQL injections, XSS vulnerabilities, insecure cryptography, and similar issues directly in the code.

The policy requires that SAST scans are automatically executed on every build or pull request. Critical findings block the build and must be resolved before merging.

Software Composition Analysis (SCA)

SCA tools check the third-party libraries and frameworks in use for known vulnerabilities (CVEs). Given that modern applications consist of 70–90 percent third-party code, this is indispensable.

The policy requires that SCA scans are performed regularly and automatically, that libraries with known critical vulnerabilities must not reach production, and that a process exists for timely updates of affected dependencies.

Dynamic Application Security Testing (DAST)

DAST tools test the running application from the outside, as an attacker would. They find vulnerabilities that SAST cannot detect, such as configuration errors, missing security headers, or authentication issues.

The policy recommends DAST scans in the staging environment before every release and defines how to handle the results.

Penetration tests

For applications with high protection requirements, the policy additionally requires manual penetration tests by qualified testers. Frequency depends on the risk profile: annually for business-critical applications, with every major release, or with significant architectural changes.

Securing development environments

The policy also addresses the security of the development environments themselves:

Environment separation: Development, test, staging, and production are strictly separated from each other. Developers have no direct access to production systems.

No production data in development environments: If tests require realistic data, anonymized or synthetic test data is used. Personal or confidential production data has no place in development and test environments.

Access control: Access to repositories, build servers, and deployment tools is governed by the least-privilege principle. Only those working on a project have access to its repository.

Branch protection: The policy requires branch protection rules for the main branch: no direct commits, only merges after code review and successful automated tests.

Code reviews and peer reviews

Automated tools find many but not all vulnerabilities. Code reviews by other developers are an indispensable complement.

The policy requires that every code change is reviewed by at least one other person before merging into the main branch. For security-critical modules (authentication, authorization, cryptography, payment processing), the policy recommends review by a person with security expertise.

Code reviews should not only check functionality but explicitly also consider security aspects. A checklist in the policy appendix can help:

• Are all inputs validated?
• Are permission checks in place at all relevant points?
• Are error messages secure (no sensitive information)?
• Are secrets handled correctly?
• Are the libraries used up to date?
• Are logs written correctly (no sensitive data logged)?

Dependency management

Third-party libraries are the blind spot of many development organizations. The Log4Shell vulnerability (CVE-2021-44228) painfully demonstrated what happens when a widely used library contains a critical flaw. A separate article describes how to systematically set up dependency scanning.

The policy defines the following requirements:

Inventory: All third-party libraries in use are documented in a Software Bill of Materials (SBOM). Tools like Syft, CycloneDX, or SPDX automate creation.

Regular review: Automated SCA scans continuously check dependencies for known vulnerabilities.

Update process: The policy defines timelines for security updates of dependencies: critical vulnerabilities within 48 hours, high within 14 days, medium in the next regular release cycle.

Approved list: For security-critical applications, the policy may define an approved list for libraries and frameworks. Only reviewed and approved dependencies may be used.

License compliance: Clean dependency management also addresses license compliance, which is relevant when using open-source components.

Deployment and release management

The policy also governs the transition from development to production:

Automated deployment: Deployments are performed through the CI/CD pipeline, not manually. Manual interventions on production systems are only permissible in documented emergencies.

Release approval: Before every release to the production environment, an approval confirms that all defined security checks have passed: SAST, SCA, DAST (where applicable), code review, functional tests.

Rollback capability: Every deployment must be reversible. The policy requires that rollback procedures are documented and tested.

Change management: Changes to production systems are documented within the change management process and are traceable.

External development

When external service providers develop software on commission, the same security requirements apply. A supplier security policy provides the overarching framework for all requirements for third parties. The policy specifies:

• External developers are obligated to follow the secure coding guidelines.
• Code from external developers is subject to the same review and testing requirements.
• Before adoption into the production environment, the code is reviewed internally (security audit).
• Contractual provisions ensure that security requirements are met and vulnerabilities are resolved promptly.
• Rights to the source code and the obligation to fix vulnerabilities are contractually regulated.

Example outline

1. Purpose and scope
2. Terms and definitions — SDLC, SAST, DAST, SCA, SBOM
3. Normative references — ISO 27001 A.8.25–A.8.28, NIS2 Art. 21 No. 5, OWASP
4. Principles — Security by design, least privilege, defense in depth
5. Security requirements in the planning phase — Threat modeling, data classification
6. Architecture and design principles
7. Secure coding guidelines — Input validation, output encoding, cryptography, secrets
8. Code reviews — Process, checklist, security review
9. Automated security checks — SAST, SCA, DAST in the CI/CD pipeline
10. Dependency management — SBOM, update timelines, approved list
11. Development environments — Separation, access control, test data
12. Deployment and release — Automation, approval, rollback
13. Penetration tests — Frequency, scope, follow-up
14. External development — Requirements, contracts, code adoption
15. Responsibilities
16. Training and awareness — Developer training, frequency
17. Exceptions and risk acceptance
18. Review and update
19. Effective date and approval

From policy to development culture

A secure development policy can only be effective if it is understood and accepted by developers. Security must not be perceived as a bureaucratic obstacle that slows down development, but rather as a quality attribute that distinguishes professional software development.

Regular training on secure development, exchange about current vulnerabilities, and a security champion program (one developer per team who serves as a security point of contact) help anchor security as part of the development culture.

ISMS Lite maps the complete policy lifecycle: you create the secure development policy (with AI support if needed), version every change, obtain developer acknowledgment, and have management approve it with a signature. This gives you the evidence at any time that your organization does not merely proclaim secure software development but has documented and bindingly regulated it.

Further reading

• Building vulnerability management: Process, tools, and practice
• Patch management for mid-market companies: Systematic instead of reactive
• Change management in the ISMS: Steering changes securely
• Classification policy: Confidential, internal, public
• Policy lifecycle: From creation to retirement