Skip to content

Secure Development Standards

Version History

Version Date Description/Updates
0.1 2026-06-02 Initial draft.
0.2 2026-07-23 Updated after alignment review against ISO/IEC 27001:2022, OWASP ASVS/SAMM, and related DHI Development standards. Added evidence expectations, and updated security scanning direction: new GitHub-hosted solutions and projects should use GitHub Advanced Security; existing solutions may continue using Snyk while planning a gradual move to GitHub Advanced Security.

Contacts

Section listing who are working on the standards. The list must be approved by the Architecture Board.

Group Contacts Description
Standard Owner kth
Task force jgr; frt; mbn
Stakeholders TBD
Approver(s) Architecture Board; Na'Tosha Bard

Roles to Apply

The following development roles should know at apply the standards.

Development roles:

  • Architects
  • Backend developers
  • Frontend developers
  • Infrastructure/DevOps Engineers
  • Product Manager/Product Owners
  • Testers

Enforcement Levels

The following enforcement levels apply to the sections of the standards. For terminology see Standard Enforcement Levels.

This table decides how far each section reaches. Where a section is Expected it applies to new products and projects, and to an existing product from the point it undergoes a material rework of the area the section covers. Where a section is Mandatory it applies to all products and projects. The modal verbs used inside a section describe how the expectation is met; they do not raise or lower the level set here. Departures are handled as exceptions per section 11.

Section Enforcement Level When/what
Evidence & Documentation Requirements Mandatory Every product or project in scope. The evidence set scales with the sections that apply to the product.
1. Security Principles Important All products and projects, as design intent rather than a per-item check.
2. Secure Development Life Cycle (SDLC) Gates Expected New products and projects. Existing products adopt the gates as their delivery process is reworked.
3. Threat Modelling Expected New products and services, major feature additions, and significant architectural change.
4. Secure Coding Standards Mandatory All code in all products and projects. Subsection 4.5 applies where a product ships an AI or language-model feature.
5. Security Scanning & Tooling Expected All repositories with a CI/CD pipeline. New GitHub-hosted repositories from creation.
6. Dependency, third party components & Supply Chain Management Mandatory All products and projects that consume third party components.
7. Secrets Management Mandatory All products, projects and pipelines.
8. Security Testing Expected Per the Applies to column in section 8.
9. Code Review & Change Management Mandatory All repositories.
10. Environment Separation & Access Control Expected Products deployed to shared or customer-facing environments.
11. Governance & Exceptions Mandatory All products and projects.
12. Vulnerability Disclosure & Product Security Response Mandatory Any product released to a customer or deployed for external use.

References

Executive Summary

These standards establish mandatory security practices for all software developed within DHI, covering:

  • desktop applications (native and .NET)
  • web applications
  • services

They align with ISO/IEC 27001:2022:

  • specifically Annex A controls 8.25 (Secure Development Life Cycle), 8.28 (Secure Coding), and 8.29 (Security Testing in Development)
  • and integrate tooling from Microsoft Code Analysis (Roslyn Analyzers), Snyk, and GitHub Advanced Security into the development workflow.

New solutions and new projects hosted in GitHub should use GitHub Advanced Security as the preferred security scanning capability.

Existing solutions may continue using Snyk where it is already implemented, but teams are recommended to start planning a gradual move to GitHub Advanced Security when practical and when equivalent controls are available. [konfirmity.com], [iso27001pro.com]

The three controls above are the ones the standard is built around; the full set of Annex A controls this standard implements, and the mapping to the NIST Secure Software Development Framework, are in the Standards Alignment appendix.

Only high-priority sections are included. Lower-priority topics (e.g., physical security of dev workstations, disposal procedures) are deferred to supplementary appendices.

Scope & Applicability

Dimension Coverage
Application types Desktop (native Win32, .NET/WPF/WinUI/MAUI), Web (SPA, server-rendered, Blazor), Services (REST/gRPC APIs, background workers, microservices)
Languages & runtimes C#/.NET (primary), TypeScript/JavaScript, Python — and any future stack adopted by DHI
Environments Development, Test/QA, Staging, Production
Teams All product and platform development teams within DHI

ISO 27001 reference: Annex A 8.31 requires strict separation of development, test, and production environments. No developer shall have direct write access to production. [hightable.io]

Authoritative source

This standard is the authoritative source at DHI for the choice of security scanning tool, the finding-severity and remediation policy, and the secure development requirements set out below. Where another DHI standard defers to security guidance for those subjects, it defers to this standard. Where a genuine contradiction remains between this standard and another DHI standard, raise it with the Architecture Board rather than following whichever document is closest to hand.

New and existing solutions

Several requirements below distinguish new from existing solutions. For the purposes of this standard:

  • A solution or project is new when its repository is created on or after 2026-01-01, or when it establishes CI/CD, branch protection or repository governance from scratch after that date.
  • Every other solution is existing.
  • An existing solution moves to the new-solution requirements for a given section when it undertakes a material rework of the area that section covers, and in all cases by 2026-12-31, when the tooling arrangements described in section 5.2 end.

Repository security record

Every repository in scope maintains a SECURITY.md file at its root. It is the single place a reviewer looks to establish how this standard is applied to that repository, and it records at minimum:

Entry Content
Authoritative scanning capability Which security scanning capability the repository's gates run on, and which pipeline enforces it.
Verification level The ASVS level targeted for web applications and APIs, and the reason where it is not the default for the product class.
Evidence locations Where each item in Evidence & Documentation Requirements is held, when it is not in the repository.
Secret rotation cadence The rotation interval in force for each class of secret the solution holds.
Security contact The named owner who receives security findings and vulnerability reports for the solution.
Approved exceptions Each approved exception, its risk owner, its compensating control and its expiry date.
Not applicable sections Any section of this standard judged not applicable to the repository, with the reason.

Evidence & Documentation Requirements

Each product or project applying these standards must maintain sufficient evidence to show that secure-development practices are applied. The evidence may be stored in the repository, a linked work item system, or another approved project location. Wherever it is held, the repository's SECURITY.md records where to find each item, so that a reviewer can locate the evidence without asking the team.

Minimum evidence:

Evidence Description
Security requirements and data classification notes A short record of the security needs for the solution, such as authentication, authorization, privacy, regulatory requirements, and whether the solution handles public, internal, confidential, or sensitive data. This helps ensure security is considered from the requirements phase, not added later.
Threat model for new products, major features, and significant architectural changes A structured analysis of what could go wrong from a security perspective, including likely threats, attack surfaces, and required mitigations. It should be created when building something new or making changes that materially affect the architecture or risk profile.
Security architecture decisions or ADRs for material security choices Architecture Decision Records should document important security choices, such as authentication model, encryption approach, secrets handling, network exposure, or use of third-party components. The purpose is to make the rationale, trade-offs, and consequences visible for future reviewers and maintainers.
Scan results or pipeline evidence for SAST, SCA, secrets detection, IaC/container scanning where applicable Teams should keep evidence that automated security checks have run and passed, for example from CI/CD pipeline logs or security tool dashboards. This covers source-code scanning, dependency vulnerability scanning, secret detection, infrastructure-as-code checks, and container scanning when relevant.
Approved exceptions and risk acceptances, including expiry date and compensating controls If a team cannot comply with a security requirement, the exception must be explicitly approved and documented. It should include why the exception is needed, who accepted the risk, how long it is valid, and what compensating controls reduce the risk meanwhile.
Release security checklist for production releases A checklist used before production release to confirm that required security activities have been completed. Typical items include scan status, secrets handling, access control, environment configuration, known vulnerabilities, and approved exceptions.
Security testing evidence for web applications, APIs and externally exposed services Evidence that security-relevant tests were performed for systems exposed to users, integrations, or the internet. This may include API authorization tests, OWASP Top 10 / ASVS checks, penetration-test reports, DAST results, or documented manual verification.

For web applications and APIs, teams should use OWASP ASVS 5.0 as the preferred detailed verification checklist. Level 1 is the floor for any web application or API. Level 2 is the default for a product that authenticates users, or that processes personal, confidential or contractual data, which covers most of what DHI ships; ASVS positions Level 1 as the set of controls verifiable largely from the outside and Level 2 as the level business-critical applications should aim for. Level 3 applies where a breach would be catastrophic. A product may target a different level where a product-specific risk assessment justifies it, or record a documented non-applicability decision.

Record the level chosen for a product in its SECURITY.md, with the reason where it departs from the default for that product class. A level is a commitment to verify against that level's requirements, so it has to be a decision the team made and can point to, not one a reviewer infers.

1. Security Principles

All DHI software must adhere to the following principles across desktop, web, and service applications:

# Principle Description
1 Defence in Depth Apply multiple, overlapping security controls so that failure of one does not compromise the system.
2 Least Privilege Grant only the minimum permissions required for a user, service, or process to perform its function.
3 Secure by Default Ship with the most restrictive, secure configuration; require explicit opt-in for less-secure options.
4 Fail Securely On error, deny access and avoid exposing internal state, stack traces, or sensitive data.
5 Zero Trust Authenticate and authorise every request regardless of network location; never trust implicit context.
6 Input Validation & Output Encoding Validate all input at the boundary; encode all output to prevent injection attacks (SQL, XSS, command).
7 Separation of Duties Ensure no single individual can both develop and deploy code to production without independent review.
8 Audit & Traceability Log security-relevant events and maintain tamper-evident audit trails for forensic analysis.

2. Secure Development Life Cycle (SDLC) Gates

Security is not an afterthought. Each phase of the SDLC has a mandatory security gate that must be passed before proceeding. This directly satisfies ISO 27001 Annex A 8.25. [konfirmity.com], [hightable.io]

Phase Security Gate Key Activities
1. Requirements Security requirements sign-off Identify data classification, regulatory constraints, authentication/authorisation needs, and privacy requirements.
2. Design Threat model review Perform threat modelling (STRIDE or equivalent); document attack surface; define security controls in the architecture.
3. Implementation Automated scan pass (green build) Apply secure coding standards; run Roslyn Analyzers and the repository-authoritative security scans. New GitHub-hosted solutions and projects should use GitHub Advanced Security; existing solutions may continue using Snyk while planning migration. Peer-review all code changes.
4. Testing Security test completion Execute SAST, SCA, DAST, and (where required) penetration testing; verify all critical/high findings are resolved.
5. Deployment Release security checklist Validate environment hardening, secrets management, and configuration; obtain release approval.
6. Operations Continuous monitoring Monitor for new CVEs using the repository-authoritative scanning capability. For new GitHub-hosted solutions and projects this should be GitHub Advanced Security; existing solutions may continue using Snyk. Respond to incidents per the incident response plan; schedule periodic re-assessment.

3. Threat Modelling

Mandatory for: All new products, services, and major feature additions.

3.1 When to Perform

  • At the design phase of every new project or significant architectural change.
  • Annually for existing products as part of the security review cycle.

3.2 Method

  • Use STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) as the baseline methodology.
  • Tool recommendation: Microsoft Threat Modeling Tool or OWASP Threat Dragon. [iso27001pro.com]

3.3 Output

  • A threat model document listing identified threats, risk ratings, and mitigating controls.
  • Threat models must be stored in the project repository at docs/threat-model.md, or under docs/threat-models/ where a solution needs more than one. Security decisions arising from the threat model are recorded as architecture decision records at docs/adr/adr-NNN-short-title.md.
  • Each threat model states the date it was last reviewed and the person who reviewed it, so the annual review cycle above can be verified.

4. Secure Coding Standards

All developers must follow these standards, which map to ISO 27001 Annex A 8.28 (Secure Coding). [konfirmity.com]

4.1 General (All Application Types)

  • No hardcoded secrets. Use a secrets manager (e.g., Azure Key Vault, HashiCorp Vault). Secrets in source code will be flagged by Snyk and must be remediated before merge.
  • Parameterised queries only. Never construct SQL via string concatenation (Roslyn rule CA2100). [offensive360.com]
  • Use current cryptographic algorithms. SHA-256+ for hashing; AES-256 for symmetric encryption. MD5 and SHA-1 are prohibited (Roslyn rules CA5350, CA5351). [offensive360.com]
  • Validate all input. Apply allowlists, length constraints, and type checks at the application boundary.
  • Encode all output. Context-appropriate encoding (HTML, URL, JavaScript, SQL) to prevent injection.
  • Handle errors securely. Never expose stack traces, internal paths, or connection strings to end users.
  • Minimise attack surface. Disable unused features, endpoints, and debug modes in non-development builds.

4.2 Desktop Applications (.NET / Native)

Concern Standard
Code signing All released binaries must be digitally signed with DHI's code-signing certificate. Signing is performed by the release pipeline through the central DHI signing service; developers do not hold the certificate. Name the signing service and the certificate owner used by the product in its SECURITY.md, and refer to the NuGet publishing policy for package and assembly signing.
Signing key custody Code-signing private keys are generated and held in a hardware security module meeting FIPS 140-2 Level 2 or Common Criteria EAL4+ and are not exportable, which publicly trusted certificate authorities have required since June 2023. Every production signature is timestamped (RFC 3161) so that it remains verifiable after the signing certificate expires.
Auto-update Implement secure update channels with signature verification to prevent tampering. The update client verifies the signature and the certificate chain before executing anything it downloaded, and refuses to downgrade to an earlier version.
Local data protection Use DPAPI or platform-equivalent for protecting locally stored credentials and tokens.
Privilege Applications must run at standard user privilege; request elevation only when strictly necessary and with explicit user consent.
Memory safety Avoid unsafe code blocks in C#. For native code, use bounds-checked APIs and build with the current hardening switches: /guard:cf for control flow guard, /Qspectre, /sdl, and /CETCOMPAT on 64-bit binaries. ASLR and DEP are on by default in supported toolchains and are not sufficient on their own. Prefer a memory-safe language for new components rather than adding to an existing native codebase.

4.3 Web Applications

Concern Standard
OWASP Top 10 All web applications must be assessed against the current OWASP Top 10 and mitigate all identified risks.
Authentication Use DHI IAM and/or industry-standard protocols (OAuth 2.0 / OpenID Connect). No custom authentication schemes.
Session management Use secure, HttpOnly, SameSite cookies; enforce session expiry and re-authentication for sensitive operations.
CSP & security headers Enforce Content-Security-Policy including a frame-ancestors directive, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Framing is controlled by frame-ancestors; browsers ignore X-Frame-Options when both are present, so keep X-Frame-Options only as a fallback for clients that predate CSP. Add the cross-origin isolation headers where the application handles cross-origin content.
CSRF protection Anti-forgery tokens are mandatory for all state-changing operations.
TLS Enforce TLS 1.3 where the platform and the client base support it, with TLS 1.2 as the lowest permitted fallback. Disable TLS 1.1 and earlier, and disable cipher suites without forward secrecy.

4.4 Services (APIs & Background Workers)

Concern Standard
Authentication & authorisation All API endpoints must require authentication (bearer tokens / mutual TLS). Apply role-based or attribute-based access control.
Rate limiting & throttling Implement rate limiting on all public-facing endpoints to prevent abuse and denial-of-service.
Input validation Validate request payloads against a defined schema (e.g., OpenAPI / JSON Schema). Reject malformed requests.
Logging Log authentication events, authorisation failures, and data access patterns. Never log secrets, tokens, or PII in plaintext. This section sets which security events must be emitted; retention, masking, alerting on those events and the operational signals around them are owned by the Monitoring and Observability standard.
Service-to-service Use managed identities or short-lived certificates; no shared static API keys between services.
API versioning Deprecate and retire insecure API versions on a documented schedule.

4.5 AI and LLM Features Shipped in Products

This subsection applies where a DHI product embeds a language model, an agent, or a retrieval pipeline as a product feature. It is separate from the use of AI tools during development, which the Artificial Intelligence policies & guidelines cover. Assess such features against the OWASP Top 10 for Large Language Model Applications and apply the following as a minimum:

Concern Standard
Prompt injection Treat all model input as untrusted, including content the model retrieves rather than content the user typed. Indirect injection through a fetched document, web page or file is the case to design for. Instructions from retrieved content must never be able to change the system prompt, the tool set or the authorisation context.
Output handling Treat model output as untrusted input to whatever consumes it. Encode it for its destination and never pass it unchecked into a shell, a query, a browser context or a file path.
Authorisation of tools and data A model or agent acts with the calling user's permissions, never with a broader service identity. Tool invocation is allowlisted, and every tool call is authorised on the server side rather than trusted because the model asked for it.
Sensitive information disclosure Prevent the model from returning data the caller is not entitled to, including data reachable through the retrieval index. Do not place secrets or customer data in system prompts.
Data and model provenance Record which model, version and provider a feature uses, and where any fine-tuning or retrieval data came from. Third-party models and datasets are third-party components under section 6.
Resource limits Apply rate limits and cost or token ceilings per caller, so that a feature cannot be driven into unbounded consumption.
Logging Log prompts, tool calls and decisions sufficiently to investigate an incident, while applying the PII rules in section 4.4 to prompt content.

5. Security Scanning & Tooling

Automated security scanning is mandatory in every CI/CD pipeline. Two primary tools are prescribed. [learn.microsoft.com], [devsecopsschool.com]

5.1 Microsoft Code Analysis (Roslyn Analyzers)

Purpose: Static Application Security Testing (SAST) for C#/.NET code, integrated at compile time.

Aspect Detail
Scope All .NET projects that build product code (desktop, web, services), and test and tooling projects in the same solution. Generated code is excluded by the analyzers' own default. Any other excluded project is listed with its reason in SECURITY.md.
Activation The analyzers ship with the .NET SDK and run during build for projects targeting .NET 5 or later, but the Security category is off in the SDK's default analysis mode. Turn it on with <AnalysisModeSecurity>All</AnalysisModeSecurity>.
Key security rules CA2100 (SQL Injection), CA3001 (XSS), CA3002-CA3012 (various injection), CA5350-CA5403 (weak crypto, insecure deserialization) [offensive360.com]
Severity enforcement Enable the Security category, then treat its diagnostics as errors so they block the build. Escalating a rule that is not enabled has no effect, because a disabled rule reports nothing to escalate.
CI/CD No extra pipeline switch is needed: the analyzers run as part of dotnet build, so the build gate is what enforces them. Keep the properties in source control rather than setting them on the build agent.

Required .csproj configuration:

<PropertyGroup>
  <!-- Required only for projects that do not target .NET 5 or later. -->
  <EnableNETAnalyzers>true</EnableNETAnalyzers>
  <AnalysisLevel>latest-recommended</AnalysisLevel>
  <!-- Enables every rule in the Security category. The default mode leaves them off,
       and a rule that is off cannot be escalated by WarningsAsErrors. -->
  <AnalysisModeSecurity>All</AnalysisModeSecurity>
  <WarningsAsErrors>CA2100;CA3001;CA3002;CA3003;CA3004;CA3005;CA3006;CA3007;CA3008;CA3009;CA3010;CA3011;CA3012;CA5350;CA5351;CA5358;CA5359;CA5360;CA5361;CA5362;CA5363;CA5364;CA5365;CA5366;CA5367;CA5368;CA5369;CA5370;CA5371;CA5372;CA5373;CA5374;CA5375;CA5376;CA5377;CA5378;CA5379;CA5380;CA5381;CA5382;CA5383;CA5384;CA5385;CA5386;CA5387;CA5388;CA5389;CA5390;CA5391;CA5392;CA5393;CA5394;CA5397;CA5398;CA5399;CA5400;CA5401;CA5402;CA5403</WarningsAsErrors>
</PropertyGroup>

These settings may be declared once in a solution-level Directory.Build.props rather than repeated in every project file; a repository that does so satisfies this section.

The rule list above has to be extended as new security rules ship with the SDK. A repository that would rather not track the list can set <TreatWarningsAsErrors>true</TreatWarningsAsErrors> instead and fix all build warnings; either approach satisfies this section. Do not rely on a bulk dotnet_analyzer_diagnostic.category-Security.severity entry in .editorconfig to do this work: a bulk severity entry only reaches rules that are already enabled, and it is ignored altogether once enablement is driven from MSBuild properties.

5.2 Snyk and GitHub Advanced Security

DHI uses Snyk today in existing solutions where it is already implemented and operational. Existing solutions may continue using Snyk as their security vulnerability checking software.

For new solutions and new projects hosted in GitHub, the preferred direction is to use GitHub Advanced Security for security scanning. This applies especially to repositories created directly in GitHub Enterprise or projects that are setting up new CI/CD, branch protection, and repository governance from scratch.

It is recommended that existing solutions start moving towards GitHub Advanced Security when practical. The move should be planned as a controlled transition rather than a sudden tool replacement.

GitHub Advanced Security is not a single switch. It is the umbrella name for two separately licensed products plus capabilities that every repository already has, and a migration plan has to name the capability rather than the umbrella:

Capability Product What it replaces from the Snyk set
Code scanning with CodeQL, Copilot Autofix, security campaigns, dependency review GitHub Code Security (licensed per active committer) Snyk Code
Secret scanning and push protection GitHub Secret Protection (licensed per active committer) Snyk Secrets
Dependabot alerts, security updates and version updates Included for every repository at no additional cost Snyk Open Source
Container and infrastructure-as-code scanning Not provided by either product. Keep Snyk Container and Snyk IaC, or select another scanner and record the choice Snyk Container, Snyk IaC

A migration plan that assumes the umbrella product covers container and IaC scanning will leave those two controls uncovered. Confirm the licensing position for the two paid products before a repository's gates are made to depend on them.

Transition principles:

  • New GitHub-hosted solutions and projects should use GitHub Advanced Security as the default security scanning capability.
  • Existing solutions can keep using Snyk while it remains operational and provides the required security gates.
  • Teams should start planning migration to GitHub Advanced Security when modernising repositories, CI/CD pipelines, branch protection rules, or security gates.
  • Do not remove existing Snyk checks before replacement GitHub Advanced Security controls are configured, validated, and accepted by the responsible standard owner/security owner.
  • Branch protection and required status checks must reflect the tool currently authoritative for the repository. Which capability is authoritative is recorded in the repository's SECURITY.md, so that the required status checks and the recorded decision can be compared.
  • Exception handling and risk acceptance must be independent of the tool used to detect the issue.

5.2.1 Snyk

Purpose: Software Composition Analysis (SCA), container scanning, code analysis (SAST), Infrastructure-as-Code (IaC) scanning, and secrets detection. [devsecopsschool.com], [fullstacks.io]

Where Snyk remains in use, a Snyk login and organisation is obtained from Morten Bentzen.

Aspect Detail
GitHub Advanced Security for new GitHub-hosted solutions/projects, Snyk Open Source for existing solutions where already implemented (SCA) Scan all third-party dependencies (NuGet, npm, pip) for known CVEs. Runs on every PR and nightly.
Snyk Code (SAST) AI-driven static analysis for proprietary code. Complements Roslyn for cross-language coverage (TypeScript, Python).
Snyk Container Scan Docker/container images for OS-level and library vulnerabilities before deployment.
Snyk IaC Scan Terraform, Kubernetes manifests, and ARM/Bicep templates for misconfigurations.
GitHub Advanced Security secret scanning for new GitHub-hosted solutions/projects, Snyk Secrets for existing solutions where already implemented Detect hardcoded credentials, API keys, and tokens in source code.

Integration points:

Integration Point How
IDE Install the Snyk plugin for Visual Studio / VS Code / JetBrains IDEs for real-time feedback. [medium.com]
Pull Request Snyk automatically scans PRs, comments with findings, and can suggest auto-fix PRs for dependency upgrades. [medium.com]
CI/CD Pipeline Run snyk test (fail build on critical/high) and snyk monitor (continuous tracking) in every pipeline.
Dashboard Security leads monitor the Snyk dashboard for organisation-wide vulnerability trends and SLA compliance.

5.3 Scan Policy & SLA

Severity Build Gate Remediation SLA
Critical 🛑 Build blocked Contain or mitigate within 1 day; fix within 7 days
High 🛑 Release pipeline blocked; ⚠ī¸ warning on pull-request builds Fix within 30 days
Medium ℹī¸ Informational Fix within 90 days or accept risk with documented justification
Low ℹī¸ Informational Accept risk with documented justification

The SLA clock starts when the finding is first reported by the repository's authoritative scanning capability, and it is measured against the default branch. A finding that a team has fixed on a feature branch is still open until the fix reaches the default branch. Findings the team has not triaged are counted as open at their reported severity.

Severity alone does not decide urgency. A finding is treated on the Critical track regardless of the severity the scanner assigned it when either of the following holds, because both say the vulnerability is being exploited in practice rather than in theory:

  • The underlying CVE is listed in the CISA Known Exploited Vulnerabilities catalogue.
  • The CVE has an EPSS score above 0.5, or a working public exploit exists for it.

The reverse also applies: a high-severity finding in a component the product does not reach at run time may be de-prioritised, provided the reachability argument is written down and the finding stays visible until it is fixed. Suppressing it silently is not the same thing.

Exception process: If a critical finding cannot be fixed within the SLA (e.g., no upstream patch available), the team must file a risk acceptance with the Architecture Board, including a compensating control plan.

6. Dependency, third party components & Supply Chain Management

Open-source and third-party components are a significant attack vector, and supply chain failures are now a category of their own in the OWASP Top 10. ISO 27001 Annex A 5.19 and A 5.21 cover security in supplier relationships and in the ICT supply chain, and A 8.30 covers development carried out by an external party. [sprinto.com]

  • Approved sources only. Dependencies must come from approved registries (nuget.org, npmjs.com, PyPI). Internal proxies are recommended.
  • Lock files mandatory. All projects must use lock files (packages.lock.json, package-lock.json, poetry.lock) committed to the repository.
  • Automated vulnerability monitoring. GitHub-hosted repositories enable Dependabot alerts and Dependabot security updates. These are available to every repository at no additional cost and are not part of either licensed GitHub security product, so there is no licensing reason for a GitHub-hosted repository to be without dependency vulnerability detection. Existing solutions may continue using Snyk Open Source where already implemented and operational. [devsecopsschool.com]
  • Licence compliance. All dependencies must have licences compatible with DHI's licence policy. Licence scanning must be enabled using the repository-authoritative scanning tool. Existing solutions may continue using Snyk licence scanning where already implemented.
  • Update cadence. Dependencies with known vulnerabilities must be updated per the SLA in section 5.3. All other dependencies should be reviewed quarterly.
  • Software bill of materials. Every released product generates an SBOM in a standard machine-readable format (CycloneDX or SPDX) as part of its release pipeline, stores it with the release record, and retains it for the supported life of the release. The SBOM is what makes it possible to answer, within hours rather than weeks, whether a newly disclosed vulnerability affects a shipped product.
  • Build-time dependencies are part of the supply chain. Third-party CI/CD actions and tasks are pinned to a full commit SHA rather than a tag or a major version, because a tag can be repointed by anyone with write access to the action's repository. Workflow tokens are granted the least privilege the job needs, and workflows that hold release credentials do not run on untrusted pull requests.
  • Externally developed code. Where development is carried out by a contractor, an agency or another external party, the contract requires the practices in this standard, and the delivered code passes the same gates as internally written code before it is merged. The reviewing DHI team, not the supplier, confirms the gates passed.

Please apply to the DHI Open Source Software Policy

7. Secrets Management

  • Never store secrets in source code, configuration files, or stored pipeline variables. A secret injected into a process at run time by the platform or the vault is acceptable and is how the vault integrations below work; what is prohibited is a secret that persists in a file, a repository, an image or a saved pipeline setting.
  • Prefer removing the secret over storing it. Where the platform supports it, use managed identities, workload identity federation from the pipeline to the cloud subscription, and short-lived tokens, so there is no long-lived credential to leak or rotate. Rotation policy applies to the secrets that remain.
  • Use Azure Key Vault (or approved equivalent) for all secrets, certificates, and connection strings.
  • Rotate secrets on a defined schedule (minimum annually; immediately upon suspected compromise). The product team sets the interval for each class of secret it holds and records it in SECURITY.md; annual is the longest interval permitted, not the target.
  • Secrets scanning must be enabled in all repositories. Existing solutions may continue using Snyk Secrets where already implemented. New GitHub-hosted solutions and projects should use GitHub Advanced Security secret scanning where available. [medium.com]
  • A secret found committed to a repository is treated as compromised. Rotate it first, then remove the value from history and record the event with the security contact named in SECURITY.md. Removing the value from history without rotating it does not close the exposure.
  • CI/CD pipelines must pull secrets at runtime from the vault; secrets must never be baked into build artefacts.

8. Security Testing

This section defines security-specific testing requirements. The broader testing lifecycle, test states, sign-off, test data management, and quality metrics are owned by the Testing Standards and should be referenced when planning implementation.

Aligns with ISO 27001 Annex A 8.29 (Security Testing in Development). [konfirmity.com]

Test Type Tool(s) When Scope Applies to
SAST Roslyn Analyzers, GitHub Advanced Security for new GitHub-hosted solutions/projects, Snyk Code for existing solutions where already implemented Every build & PR All source code All products and projects
SCA GitHub Advanced Security for new GitHub-hosted solutions/projects, Snyk Open Source for existing solutions where already implemented Every build & PR; nightly monitor All dependencies All products and projects that consume third party components
DAST OWASP ZAP / Snyk API & Web Pre-release; scheduled weekly in staging Web applications & APIs [snyk.io] Web applications and APIs reachable from outside the product's own deployment, including customer-facing and partner-facing endpoints
Container Scan Snyk Container Every image build All container images Solutions that build or ship container images
IaC Scan Snyk IaC Every PR changing infra templates Terraform, K8s, ARM/Bicep Repositories that hold infrastructure templates
Penetration Testing External vendor / internal red team Annually; before major releases Full application stack Internet-exposed products that process confidential or personal data. Commissioned by the Architecture Board, not by the product team. Not required for other product classes; record the decision in SECURITY.md
Secrets Detection GitHub Advanced Security secret scanning for new GitHub-hosted solutions/projects, Snyk Secrets for existing solutions where already implemented Every PR All repositories All repositories

9. Code Review & Change Management

  • All code changes must be submitted via pull request and reviewed by at least one independent reviewer before merge. One reviewer is the floor set here; where the GitHub Governance standard sets a higher number of required approvals for a repository's tier, that number applies.
  • Reviewers must verify:
  • Adherence to secure coding standards (section 4).
  • All automated scans pass (section 5).
  • No secrets, PII, or sensitive data in the diff.
  • Appropriate logging and error handling.
  • Branch protection rules must be enforced: no direct pushes to main/release branches; required status checks for Roslyn and the repository-authoritative security scanning tool. New GitHub-hosted solutions/projects should use GitHub Advanced Security; existing solutions may continue using Snyk.
  • The branches that must be protected are the long-lived branches the repository's branching strategy defines, as set out in the Version Control & Branching Strategy standard: main under Trunk-Based Development, and dev, staging and production under Environment Branching, plus any release/* branch still supporting a released line. Protecting only a branch named main is not sufficient for a repository that promotes through environment branches.
  • All changes must be traceable to a work item (ISO 27001 change management requirement, Annex A 8.32). [sprinto.com]

10. Environment Separation & Access Control

What this section requires is separation of the environments themselves and the access rules below. The branching model that carries code between them is set by the Version Control & Branching Strategy standard, which makes Environment Branching the default for services and web applications promoted through environments and allows a documented deviation. A team using Trunk-Based Development with feature flags still has to meet every requirement in this section.

Per ISO 27001 Annex A 8.31: [hightable.io]

Environment Access
Development Developers: full access. Uses synthetic/anonymised data only.
Test/QA Developers and testers: full access. Synthetic or anonymised data only; production data must not be copied into it.
Staging Limited deployment access via CI/CD only. Mirrors production configuration. Synthetic or anonymised data unless a documented approval covers the use of production data.
Production No direct developer access. Deployments via approved CI/CD pipelines only. Break-glass access with audit logging.

Please refer to Branching Strategies and Versioning standards.

11. Governance & Exceptions

  • These standards apply to all DHI development teams at the level each section carries in the Enforcement Levels table above.
  • The Architecture Board is responsible for maintaining, reviewing (annually), and enforcing these standards.
  • Competence. Developers in the roles listed above receive secure development training on joining and refresher training annually, covering at least the OWASP Top 10 and the practices in section 4. Each product area names a security champion: a developer who is the first point of contact for security questions in that area, reviews the threat model, and carries security findings into the backlog. Without a named person the practices in this standard have no owner inside the team, which is the most common reason a secure development policy stays on paper.
  • Exceptions must be formally requested, reviewed by the Architecture Board, and documented with:
  • Justification and business rationale.
  • Compensating controls.
  • Expiry date for the exception.
  • Acceptance by a risk owner.

12. Vulnerability Disclosure & Product Security Response

The sections above address vulnerabilities found before release. This section addresses vulnerabilities found in software already in customers' hands, which the sections above do not reach.

  • Reporting channel. Every product publishes a route for reporting a suspected vulnerability, and the repository's SECURITY.md names it along with the security contact who receives reports. A finder who cannot see where to send a report will publish instead.
  • Intake and triage. Reports are acknowledged, assessed for severity and exploitability, and tracked in the same backlog as internally found findings, on the SLA in section 5.3.
  • Regulatory reporting. For products placed on the EU market, an actively exploited vulnerability must be reported to the national CSIRT and to ENISA within 24 hours of DHI becoming aware of it, under the EU Cyber Resilience Act from 11 September 2026. This obligation covers products already on the market, not only new releases, and the deadline is short enough that the reporting path must be agreed before it is needed. Route these through the DHI security organisation rather than the product team.
  • Customer notification and fix delivery. Where a vulnerability affects a released version, decide and record which supported versions receive the fix, how customers are told, and what interim mitigation they can apply. A fix that only reaches the next major release is not a response for a product with long-lived installations.
  • Traceability to the SBOM. Use the SBOM produced under section 6 to determine which released products contain an affected component, rather than reconstructing the answer per product.
  • Learning. For each significant vulnerability, record the root cause and whether a control in this standard would have caught it. Where it would not, propose the change to the Architecture Board.

Appendix: Quick-Reference — Scanner Configuration Checklist

✅ Action
☐ Roslyn AnalysisLevel set to latest-recommended, in each .csproj or once in Directory.Build.props
☐ AnalysisModeSecurity set to All, so the Security category is actually enabled
☐ EnableNETAnalyzers set to true on any project not targeting .NET 5 or later
☐ Security CA rules configured as WarningsAsErrors
☐ A verification build confirms a deliberate security violation fails the build; enabling the properties without checking is the common failure mode
☐ Security scanning integrated in CI/CD pipeline: GitHub Advanced Security for new GitHub-hosted solutions/projects; Snyk may remain for existing solutions
☐ Security scanning enabled per project type: GitHub Advanced Security for new GitHub-hosted solutions/projects; Snyk Open Source, Code, Container, IaC, and Secrets may remain enabled for existing solutions
☐ Relevant developer tooling configured: GitHub Advanced Security feedback through GitHub for new repositories; Snyk IDE plugins where Snyk remains in use
☐ Build gates configured per section 5.3: critical blocks every build, high blocks the release pipeline
☐ Security findings monitored in the authoritative tool: GitHub Advanced Security for new GitHub-hosted solutions/projects; Snyk dashboard where Snyk remains in use
☐ SBOM generated by the release pipeline and stored with the release record
☐ Third-party CI/CD actions and tasks pinned to a full commit SHA
☐ SECURITY.md present, complete, and naming a security contact

Appendix: Standards Alignment

This standard is the implementation of the following controls for DHI software development. The mapping is provided so that an auditor can move between the standard and this document without reconstructing the correspondence, and so that a gap in one is visible in the other.

ISO/IEC 27001:2022 Annex A control Where it is met
A 5.19, A 5.21 Supplier relationships and ICT supply chain Section 6
A 6.3 Awareness, education and training Section 11
A 8.8 Management of technical vulnerabilities Sections 5.3 and 12
A 8.25 Secure development life cycle Section 2
A 8.26 Application security requirements Evidence & Documentation Requirements; sections 4.3 and 4.4
A 8.27 Secure system architecture and engineering principles Sections 1 and 3
A 8.28 Secure coding Sections 4 and 5
A 8.29 Security testing in development and acceptance Section 8
A 8.30 Outsourced development Section 6
A 8.31 Separation of development, test and production environments Section 10
A 8.32 Change management Section 9
A 8.33 Test information Section 10

The NIST Secure Software Development Framework (SP 800-218) is the reference used where a practice has no direct Annex A control: its practice groups map to this standard as Prepare the Organization to sections 1 and 11, Protect the Software to sections 6, 7 and 9, Produce Well-Secured Software to sections 2, 3, 4, 5 and 8, and Respond to Vulnerabilities to sections 5.3 and 12.