Skip to main content

Developer

Overview​

Developers are the front line of the practical implementation of security by design.
It is in the act of writing code that a large part of the security practices prescribed in the SbD-ToE materialise.

Key Responsibilities​

  • Write code in accordance with security guidelines (Ch. 06)
  • Fix vulnerabilities identified in reviews and scans
  • Contribute to threat modelling and provide technical information on data flows (Ch. 03)
  • Ensure that the software meets functional and security requirements in a robust and traceable way

Organisational Context​

The Developer role is cross-cutting to almost the whole Manual. The responsibility is twofold: deliver functionality and ensure security. Without the active collaboration of developers, no security policy materialises.

Regulatory Framework​

The Developer's work gives effect to obligations under:

  • NIS2: Secure development practices and vulnerability management
  • DORA: Digital resilience in financial systems
  • GDPR: Security by design principles
  • AI Act: Security and transparency in AI systems

Activities by Chapter​

Ch. 01 - Criticality Classification​

Provide technical information on the application's dependencies, integrations and operational impact, contributing to the risk assessment and to determining the criticality level (L1/L2/L3).

User Stories:

Ch. 02 - Security Requirements​

Implement the minimum security requirements derived from the classification, integrating them into the definition of done and ensuring compliance in every delivery.

User Stories:

Ch. 03 - Threat Modelling​

Take an active part in threat modelling sessions, translating diagrams and threat scenarios into practical controls implemented in code.

User Stories:

Ch. 04 - Secure Architecture​

Ensure that the implementation respects the defined architectural patterns. Keep the architecture sheet up to date when critical changes occur.

User Stories:

Ch. 05 - Dependencies and SBOM​

Explicitly declare all libraries and dependencies used, supporting the creation of auditable inventories (SBOM) essential for vulnerability management.

User Stories:

Ch. 06 - Secure Development​

Follow secure coding guidelines, use linters and automatic validation, fix SAST findings. Prevent trivial vulnerabilities through tools integrated into the development workflow.

User Stories:

Ch. 07 - Secure CI/CD​

Collaborate with DevOps on configuring secure pipelines, ensuring that code passes through security gates (SAST, dependency check) before being merged or deployed.

User Stories:

Ch. 08 - IaC (Infrastructure as Code)​

Collaborate on the writing and validation of secure IaC templates, ensuring that infrastructure is versioned and auditable.

User Stories:

Ch. 09 - Containers and Images​

Build images from trusted, versioned bases (SHA256 digest). Ensure that Dockerfiles follow security best practices.

User Stories:

Ch. 10 - Security Testing​

Run automatic SAST on the PR with inline comments, fixing vulnerabilities before merge. Create regression tests for fixed findings.

User Stories:

Ch. 11 - Secure Deployment​

Maintain semantic versioning with a technical and security changelog. Ensure that only validated artefacts are promoted between environments.

User Stories:

Ch. 12 - Monitoring and Operations​

Implement structured, centralised logging, generating events with enough context for incident detection and investigation.

User Stories:

Ch. 13 - Training and Onboarding​

Take part in continuous upskilling programmes and, as Security Champion, lead threat modelling sessions per feature, epic or refactor.

User Stories:

Ch. 14 - Governance and Contracting​

Submit security exceptions through a formal flow with automatic routing by risk level. Maintain a structured compliance repository for each application (with the Scrum Master / Team Lead).

User Stories:


Chapter References​

For full context and framing: