N.6.02 Keeping the program code and external components up to date
Control Overview
This control mandates that organizations involved in software development establish a formalized, traceable process to ensure that proprietary program code and all embedded third-party components (such as open-source libraries, packages, and frameworks) are continuously updated with the latest security patches. Because modern software relies heavily on external upstream dependencies, the organization must actively monitor for software supply chain vulnerabilities, implement automated tracking systems, define explicit remediation timelines (SLAs) for vulnerable packages, and systematically document update compliance.
Applicability Note: This control is fully applicable to the anDREa platform, directly governing the secure development lifecycle (SDLC) and package-management ecosystem of the myDRE architecture.
Compliance & Strategic Approach
Our approach satisfying this NIS 2 requirement operates within our ISO/IEC 27001-based ISMS, treating upstream code security as a continuous, automated quality-assurance gate rather than a periodic point-in-time check.
anDREa manages dependency risks natively inside its integration pipelines. To prevent code-level vulnerabilities or outdated libraries from reaching production, we leverage a multi-layered automation suite:
- Continuous Dependency Tracking: We utilize GitHub Dependabot to monitor software manifests daily. Dependabot parses our project dependency tree against known vulnerability databases and automatically generates pull requests when updates or security patches are released.
- Pre-Deployment Static Analysis: Software updates and code increments are systematically analyzed via SonarCloud before code promotion, ensuring new libraries match our security baseline configurations.
- Binding Patch SLAs: To address the improvement area noted in our self-assessment, tracking is directly coupled with Annex A.08.08, which dictates clear, severity-based patch remediation SLAs (e.g., critical dependency flaws must be resolved within strict 24–72 hour windows).
Control Mappings & Evidence
| Framework / Document Reference | Element & Identifier | Description / Relationship to NIS 2 |
|---|---|---|
| ISO/IEC 27001 | A.08.27 - Secure system architecture and engineering principles | Mandates that principles for secure system engineering are established, documented, and applied to all software development activities. |
| ISO/IEC 27001 | A.08.25 - Secure development life cycle | Establishes the operational framework for managing code repositories, dependencies, and software lifecycle changes safely. |
| ISO/IEC 27001 | A.08.08 - Management of technical vulnerabilities | Houses the official patch management SLAs, outlining explicit remediation timelines based on exploit severity metrics (CVSS). |
| Pipeline Automation | GitHub Dependabot Configuration Files | Live repository manifests proving daily automated scanning cadences and automatic pull-request triggers for outdated libraries. |
| Operational Controls | Periodic Controls Security Logs | Documented validation histories showing that dependency alerts, security advisories, and library upgrades are audited regularly. |
Audit Summary
- Compliance Status: Fully Compliant
- Gaps Identified: None. Automated dependency scanning, static code analysis, and explicit, severity-based patch management timelines (SLAs) are fully operationalized within our core vulnerability protocols and verified via periodic security checks.