In today’s highly regulated technology landscape, the Software Development Life Cycle (SDLC) must be executed with rigor, discipline, and with increasing focus on compliance. Organizations are increasingly required to demonstrate adherence to governance frameworks, regulatory standards, and internal risk management policies.
To meet these expectations, SDLC processes must incorporate robust controls that not only ensure product quality and security but also provide clear evidence of compliance. However, many teams struggle with identifying which risks are most critical and how best to mitigate them consistently across projects.
This project aims to present a curated set of common risks encountered during the SDLC, along with their corresponding mitigations. By establishing a standardized library of controls, the goal is to streamline compliance efforts, reduce uncertainty, and promote safe, repeatable development practices aligned with regulatory expectations.
Search & Filter
Risk Catalogue
Identify potential risks in your AI implementation across operational, security, and regulatory dimensions.
Operational
1 risksConfiguration Drift
The actual state of infrastructure, application configuration, or deployment environments diverges from the known, approved, and version-controlled state, creating a growing gap between what the organisation believes is running and what is actually deployed.DescriptionUnlike unauthorised change (ri-8), which concerns individual changes that lack authorisation, configuration drift describes the cumulative divergence of actual state from declared state — often resulting from individually legitimate actions that are never reconciled with the source of truth. This divergence can result from manual changes applied directly to production systems, emergency fixes that are never backported to version control, inconsistent configuration management practices, or failures in infrastructure-as-code pipelines. Changes accumulate silently over time, undermining security controls, complicating incident response, and eroding confidence in the environment’s integrity. Configuration drift is also a primary driver of audit and compliance evidence failure (ri-5), because drifted state cannot be reconciled with the version-controlled records that auditors examine.Not all drift carries the same risk. Security-critical drift — such as changes to firewall rules, encryption settings, or authentication policies — demands immediate detection and remediation. Operational drift — such as divergence in application configuration or feature flags — may be tolerable in the short term but compounds over time. Infrastructure drift — divergence between declared IaC definitions and actual cloud resource state — can silently undo security controls that were verified at deployment time. Manual production changes — Ad hoc modifications applied directly to production infrastructure or application configuration outside the standard change management process Unreconciled emergency fixes — Hotfixes or emergency changes applied during incidents that are never backported to the source of truth in version control Infrastructure-as-code divergence — Drift between declared infrastructure definitions and the actual state of cloud resources, network configurations, or security groups Environment inconsistency — Development, staging, and production environments falling out of alignment, leading to untested configuration combinations reaching production Untracked configuration drift — Changes to feature flags, runtime parameters, database schemas, or third-party integrations that are not captured in version control or change recordsConsequences Silent security degradation — Drifted configurations can inadvertently weaken security controls — opening firewall rules, disabling encryption, relaxing authentication policies, or exposing services to unauthorised networks — without any alert or record. Unpredictable system behaviour — Applications running with configuration that differs from the tested and approved state may exhibit unexpected behaviour, data processing errors, or transaction failures that are difficult to diagnose. Failed disaster recovery — Recovery procedures based on version-controlled configuration will restore systems to a state that differs from what was actually running, potentially causing data loss, service failures, or incomplete recovery. Regulatory non-compliance — Regulators expect that organisations can demonstrate the current state of their systems and that changes are controlled and auditable. Configuration drift directly undermines this expectation and can trigger findings under SOX Section 404, PCI DSS Requirement 1, DORA Article 9, and FFIEC examination procedures. Complicated incident response — When the actual state of systems is unknown or differs from documentation, incident responders cannot reliably assess the scope of a compromise or determine whether specific controls were in place at the time of an incident. Increased operational risk — Teams making changes based on stale documentation or incorrect assumptions about the current environment are more likely to cause outages, introduce conflicts, or break dependent services. Erosion of trust in automation — When manual changes routinely override automated configuration management, teams lose confidence in infrastructure-as-code processes, leading to a cycle of increasing manual intervention and further drift. Loss of audit evidence — When actual state diverges from version-controlled declarations, the organisation cannot demonstrate to auditors what was running at a given point in time, directly contributing to audit and compliance evidence failure (ri-5). Control evasion through cumulative drift — Individual drifts may each appear minor, but their cumulative effect can disable or weaken security controls in ways that no single change review would have approved. Incident forensics obscuration — When the actual state of systems at the time of an incident is unknown, forensic investigators cannot determine what was running, what was exposed, or what the attacker had access to, significantly impairing incident response effectiveness.Links
Security
7 risksCredential and Secret Exposure
Sensitive authentication material — such as API keys, database passwords, service account tokens, encryption keys, or certificates — is inadvertently or deliberately exposed in locations where it can be accessed by unauthorised parties, enabling compromise of production systems, customer data, and internal infrastructure.DescriptionCredential exposure commonly occurs through secrets committed to version control repositories, hardcoded credentials in application code, secrets leaked in CI/CD logs and artefacts, or credentials stored in insufficiently protected configuration management systems. Once exposed, credentials can be harvested by attackers and used to gain unauthorised access to production systems, customer data, and internal infrastructure. The exposure itself may go undetected for extended periods, particularly when secrets persist in version control history after removal from the working tree. Secrets committed to source control — API keys, passwords, or tokens checked into Git repositories where they persist in history even after removal from the working tree Hardcoded credentials in application code — Database connection strings, service account passwords, or encryption keys embedded directly in source files rather than injected at runtime CI/CD log leakage — Build and deployment pipelines inadvertently printing secrets to log output, making them visible to anyone with access to pipeline logs Secrets embedded in infrastructure-as-code and CI/CD configuration — Credentials hardcoded in Terraform state files, Ansible playbooks and variable files, CloudFormation/SAM templates, Helm values files, Kubernetes manifests, Dockerfiles, or CI/CD pipeline definitions (.github/workflows, .gitlab-ci.yml, Jenkinsfile) where they are committed to version control alongside the infrastructure they configure Insecure secret storage — Credentials stored in plaintext configuration files, environment variables without encryption, shared documents, or messaging platforms Overprivileged service credentials — Service accounts or API keys granted excessive permissions, amplifying the blast radius if the credential is compromisedConsequences Unauthorised access to production systems — Exposed credentials provide attackers with direct access to databases, APIs, cloud infrastructure, and internal services, enabling data theft, transaction manipulation, or system compromise. Customer data breach — Compromised database credentials or API keys can be used to exfiltrate customer PII, account details, and financial records, triggering breach notification obligations under GDPR, CCPA, and GLBA. CI/CD pipeline compromise — Leaked pipeline credentials enable attackers to tamper with build and deployment processes, injecting malicious code into artefacts destined for production. Regulatory penalties — Inadequate secrets management violates requirements under PCI DSS Requirement 8, SOX Section 404, DORA Article 9, and FFIEC supervisory guidance, exposing the institution to fines, enforcement actions, and mandated remediation programs. Reputational damage — Public disclosure that customer-facing systems were compromised through leaked credentials — particularly if customer funds or data were affected — severely damages institutional trust. Costly remediation — Responding to credential exposure requires emergency rotation of all potentially affected secrets, forensic investigation to determine the scope of compromise, and potential rebuilding of affected systems — all under significant time pressure.Links
Vulnerable Software in Production
Applications or their dependencies containing known security vulnerabilities are deployed to and remain running in production environments, exposing the organisation to exploitation by attackers who actively scan for and weaponise publicly disclosed weaknesses.DescriptionThis risk has two temporal dimensions. First, known-vulnerable components can enter production at build time — through inadequate vulnerability scanning during the build and release process, failure to keep dependencies up to date, or insufficient visibility into the software composition of artefacts being deployed. Second, software that was free of known vulnerabilities when deployed can become vulnerable post-deployment when new CVEs are disclosed against versions already running in production. In the second case, the software itself has not changed; the threat landscape has. This distinction matters because it demands two different sets of controls: build-time SCA gating to prevent known-vulnerable code from being deployed, and continuous runtime monitoring with patch SLAs to detect and remediate vulnerabilities disclosed after deployment.Unlike supply chain compromise (ri-10, ri-11), which concerns the deliberate introduction of malicious or tampered components, this risk focuses on the presence of known, publicly disclosed vulnerabilities that remain unaddressed in production. Attackers actively scan for known vulnerabilities and can exploit them rapidly once public disclosures are made, making timely detection and remediation critical. Unpatched known vulnerabilities (CVEs) — Production systems running software with publicly disclosed vulnerabilities that have not been patched or mitigated Outdated or end-of-life dependencies — Libraries, frameworks, or runtime components that no longer receive security updates, leaving known vulnerabilities permanently unaddressed Incomplete vulnerability scanning — Security scans that do not cover the full software stack — including transitive dependencies, container base images, and runtime libraries — leaving blind spots in vulnerability detection Delayed remediation cycles — Organisational processes that are too slow to triage, prioritise, and deploy fixes for critical vulnerabilities before they can be exploited Shadow dependencies — Components pulled in through indirect or undocumented dependency chains that are not tracked or scanned as part of the standard build processConsequences Active exploitation — Known vulnerabilities with public exploit code can be weaponised rapidly, and financial institutions are frequently targeted due to the value of the data and systems they hold. Customer data breach — Exploited vulnerabilities in web-facing applications or APIs can expose customer PII, account credentials, and transaction histories, triggering breach notification requirements under GDPR, CCPA, and GLBA. Regulatory non-compliance — Financial regulators require timely vulnerability management as a core security control. Running known-vulnerable software violates requirements under PCI DSS Requirement 6, SOX Section 404, DORA Article 7, and FFIEC supervisory guidance on patch management. Service disruption — Exploitation of vulnerabilities can lead to denial of service, data corruption, or system compromise that forces emergency shutdowns of customer-facing services. Reputational damage — Public disclosure that a breach resulted from a known, unpatched vulnerability is particularly damaging, as it signals failure of basic security hygiene to customers, partners, and regulators.Links
Unauthorised System Access
Individuals gain access to production environments, infrastructure, or sensitive systems without appropriate authorisation or without their access being fully recorded and auditable, undermining accountability, enabling data theft, and creating undetectable pathways for compromise.DescriptionThis risk focuses on access governance — the granting, scoping, monitoring, and revocation of access itself. It is distinct from insider threat (ri-1), which concerns the deliberate misuse of access by authorised personnel acting with malicious intent. An authorised user with overly broad permissions who acts maliciously is an insider threat (ri-1); the governance failure that granted them unnecessary access in the first place is this risk (ri-6). Similarly, this risk is distinct from credential and secret exposure (ri-3), which concerns the exposure of authentication material — but when exposed credentials also carry excessive privileges, the compound risk is significantly amplified.The risk extends to both external attackers who exploit weak access controls and internal personnel whose access exceeds their legitimate operational needs.Access governance: Overprivileged access — Users or service accounts granted broader permissions than required for their role, providing unnecessary access to sensitive systems, data, or infrastructure Stale access credentials — Former employees, contractors, or rotated team members retaining active access to production systems after their need for access has ended Lack of time-bound or just-in-time access — Persistent privileged access that remains active indefinitely rather than being granted on-demand for specific, justified operational needsAccess monitoring: Insufficient access logging — Systems that do not record who accessed what, when, and from where, making it impossible to detect or investigate unauthorised access Shared and generic accounts — Use of shared credentials or service accounts that obscure which individual performed a given action, undermining accountability and audit trailsConsequences Data breach and exfiltration — Unauthorised access to production databases, customer records, or internal systems enables theft of sensitive financial data, PII, and intellectual property. Fraudulent transactions — Access to transaction processing systems, payment infrastructure, or account management tools can be exploited to initiate unauthorised transfers, manipulate account balances, or conduct fraudulent activities. Regulatory violations — Financial regulators require strict access controls and audit trails for production systems. Inadequate access governance violates requirements under SOX Section 404, PCI DSS Requirement 7, DORA Article 9, and the GLBA Safeguards Rule, triggering enforcement actions. Loss of accountability — Shared accounts and insufficient logging make it impossible to attribute actions to specific individuals, undermining incident investigation, forensic analysis, and regulatory reporting obligations. Lateral movement by attackers — Overly broad access permissions enable attackers who compromise a single account to move laterally across the environment, escalating from low-value systems to critical infrastructure. Reputational damage — Disclosure that customer data or financial systems were accessed by unauthorised individuals — particularly through preventable access control failures — severely erodes customer trust and market confidence. Prolonged undetected compromise — Without comprehensive access logging and monitoring, unauthorised access can persist undetected for extended periods, increasing the scope and severity of potential damage.Links
Unauthorised Change
Unauthorised changes to source code, configuration, or build artefacts represent a significant risk to the integrity of software systems. Such changes may be introduced deliberately by malicious actors or inadvertently through inadequate controls, and can result in the deployment of compromised or untested software into production environments.DescriptionUnauthorised change encompasses any modification to software, configuration, or related artefacts that has not been subject to the appropriate review, approval, and tracking processes. This includes changes made directly to production systems, alterations to source code outside of controlled workflows, tampering with build pipelines or deployment artefacts, and modifications to configuration files that bypass formal change management processes.Unlike insider threat, which focuses on the actor, unauthorised change focuses on the act itself — the introduction of a change that lacks a verifiable, auditable chain of custody. The risk may materialise through a variety of vectors: Direct repository tampering — modifying source code or history in a version control system without going through a controlled workflow Build pipeline injection — altering build scripts, dependencies, or artefacts between the point of development and deployment Configuration modification — changing application or infrastructure configuration outside of version-controlled processes Credential compromise — an external attacker using stolen credentials to introduce changes while masquerading as a legitimate committerThe consequences of unauthorised change can be severe: malicious code may reach production undetected, compliance audit trails may be broken, and the organisation may be unable to demonstrate the integrity of its software at any given point in time.Consequences Integrity compromise — Untrusted or malicious code may be deployed into production systems, potentially affecting customers, counterparties, or financial markets. Regulatory breach — Inability to demonstrate controlled change management processes may constitute a breach of FFIEC, SOX, or PCI DSS requirements. Audit trail failure — Without a verifiable record of who changed what and when, forensic investigation following an incident becomes significantly harder. Operational disruption — Unreviewed changes introduce a higher probability of defects, misconfigurations, or incompatibilities reaching production.Links
Environment Breach
An external attacker gains the ability to run unauthorised workloads within an organisation’s production infrastructure, establishing a persistent operational presence that enables data theft, resource abuse, and lateral movement across internal systems.DescriptionWhile unauthorised system access (ri-6) concerns access governance failures, environment breach describes a more severe state: the attacker has moved beyond access to achieve persistent execution capability within the production environment, running their own code alongside legitimate services. This can result from exploitation of vulnerabilities in exposed services, compromised container orchestration platforms, misconfigured cloud IAM policies, or abuse of legitimate deployment mechanisms. The attacker operates within the organisation’s own infrastructure, making detection significantly harder and the potential impact far greater. Unauthorised container or workload deployment — Attackers deploying their own containers, serverless functions, or processes within the organisation’s orchestration platform (e.g., Kubernetes, ECS) Compromised orchestration plane — Exploitation of container orchestration APIs or management interfaces to schedule and run attacker-controlled workloads alongside legitimate services Cryptojacking and resource abuse — Attackers deploying cryptocurrency mining workloads or using compromised infrastructure for computational tasks, consuming resources and increasing costs Staging ground for further attacks — Using the breached environment as a launch point for lateral movement into other internal systems, data stores, or connected partner networks Persistent backdoor deployment — Installing persistent access mechanisms such as reverse shells, web shells, or rogue services that survive routine maintenance and restarts Insufficient runtime monitoring and detection — Absence of workload-level monitoring, anomaly detection, or runtime security tooling that would identify unauthorised processes, unexpected network connections, or anomalous resource consumption within the production environment Lateral movement across trust boundaries — Attackers leveraging initial access in one workload to move laterally — from container to host, from one namespace to cluster admin, from application tier to data tier — exploiting implicit trust relationships between componentsConsequences Deep infrastructure access — An attacker running workloads in production has broad access to the environment, potentially including network access to databases, internal APIs, secret stores, and adjacent systems that are not directly exposed to the internet. Customer data theft at scale — With operational presence in the production environment, attackers can systematically exfiltrate customer data, transaction records, and financial information over extended periods while evading perimeter-based detection. Financial losses from resource abuse — Unauthorised workloads — particularly cryptomining operations — can generate significant unexpected cloud computing costs before detection, directly impacting operational budgets. Regulatory escalation — An environment breach represents a fundamental control failure. Regulators will treat the ability of an external attacker to run workloads in a financial institution’s production environment as a critical finding, triggering mandatory incident reporting under DORA Article 17, PCI DSS Requirement 12.10, and GLBA breach notification obligations. Supply chain risk to customers — Attacker-controlled workloads running within the institution’s infrastructure can potentially intercept, modify, or inject data into legitimate business processes, affecting downstream customers and partners. Prolonged and costly incident response — Detecting and eradicating an attacker with operational presence requires thorough forensic investigation of all running workloads, comprehensive review of deployment history, and potentially rebuilding affected infrastructure from known-good state. Dwell time amplifies blast radius — The longer an attacker maintains operational presence, the more data they can exfiltrate, the more systems they can compromise, and the more difficult eradication becomes. Environment breaches that go undetected for weeks or months result in exponentially greater damage than those detected within hours. Severe reputational damage — Disclosure that an external attacker was running their own workloads inside a financial institution’s production environment represents a serious breach of trust that can significantly damage the institution’s standing with customers, partners, and regulators.Links
Dependency and Transitive Supply Chain Compromise
Malicious, tampered, or subverted software packages — including open source libraries, transitive dependencies, container base images, and language-specific registry artefacts — enter the software development lifecycle and propagate into production, enabling attackers to execute code within the organisation’s applications without directly compromising its own systems.DescriptionA single compromised upstream package can fan out across thousands of downstream consumers through transitive dependency chains before the compromise is discovered. Unlike RI-4 Vulnerable Software in Production, which concerns the presence of known, publicly disclosed vulnerabilities, this risk concerns the deliberate introduction of malicious or tampered code at the point of origin or distribution — code that is designed to evade detection and that may never receive a CVE.Detection requires visibility into the full transitive dependency graph, not just direct dependencies. Organisations that scan only their declared dependencies miss the vast majority of their actual software supply chain. The attack surface spans every language-specific package registry (npm, PyPI, Maven Central, RubyGems, NuGet, crates.io), container image registries (Docker Hub, public cloud registries), and any upstream source from which components are pulled during build. Compromised upstream packages — Malicious code injected into widely-used libraries via maintainer account takeover, social engineering of project maintainers, or exploitation of registry authentication weaknesses Transitive dependency poisoning — Malicious packages introduced deep in the dependency tree where they are pulled in automatically, often without appearing in the organisation’s declared dependency manifests or lock files Typosquatting and namespace confusion — Attackers publishing packages with names that closely resemble legitimate packages, or exploiting misconfigured dependency resolution to substitute malicious internal or public packages Dependency confusion attacks — Exploitation of package manager resolution logic to cause internal builds to pull attacker-controlled packages from public registries instead of intended private packages Abandoned and end-of-life package takeover — Unmaintained packages acquired by new maintainers who inject malicious code into subsequent releases, exploiting the trust established by the original maintainer Tampered container base images — Container base images modified to include backdoors, credential harvesters, or persistent malware, distributed through public or compromised private registriesConsequences Undetected backdoors in production — Malicious code embedded in trusted packages can persist in production systems for extended periods, providing attackers with access to sensitive data, internal APIs, and downstream systems without triggering conventional security alerts. Widespread blast radius — A single compromised package can propagate to every application that depends on it, directly or transitively, potentially affecting the entire application estate simultaneously. Breach of data privacy regulations — Exfiltration of customer PII or financial data through a compromised dependency can trigger GDPR, CCPA, and GLBA breach notification obligations, significant fines, and regulatory investigations. Supply chain propagation to customers — Organisations that distribute software built on compromised dependencies propagate the compromise to their own customers and partners, creating cascading trust failures and potential liability. Evasion of conventional security controls — Malicious code introduced through trusted supply chain channels bypasses perimeter defences, code review, and application-level security controls that assume upstream packages are benign. Costly and disruptive remediation — Responding to a supply chain compromise requires identifying all affected artefacts across the estate, determining the scope of potential data exposure, rebuilding affected systems from known-good sources, and rotating any credentials that may have been exfiltrated.Links
Build Toolchain and Service Supply Chain Compromise
CI/CD platforms, build tools, artefact registries, signing services, or third-party SaaS services used in the software build and release path are compromised, enabling attackers to inject malicious code into production artefacts without modifying source code or declared dependencies.DescriptionThis risk is distinct from RI-10 Dependency and Transitive Supply Chain Compromise, which concerns the integrity of software packages consumed as dependencies. RI-11 concerns the integrity of the tools and services that build, sign, store, and deploy those packages. A compromised build tool can inject malicious code into every artefact it produces; a compromised artefact registry can substitute tampered binaries for legitimate builds; a compromised signing service can certify malicious artefacts as trusted. Because these tools operate with elevated privileges across the entire delivery pipeline, their compromise has an outsized blast radius.The SolarWinds (2020) and Codecov (2021) incidents demonstrated that build toolchain and service compromise can persist undetected for months, affecting thousands of downstream organisations simultaneously. Compromised CI/CD platforms and build agents — Attackers gaining access to build infrastructure to inject malicious steps into pipelines, modify build scripts, or exfiltrate secrets available to the build process Pipeline secret exfiltration — Extraction of signing keys, deployment credentials, API tokens, or cloud provider credentials from CI/CD environments, enabling subsequent attacks on production systems Artefact registry tampering — Modification or substitution of build artefacts in package registries, container registries, or binary repositories after legitimate builds have completed Signing service compromise — Compromise of code-signing infrastructure, enabling attackers to produce artefacts that pass signature verification and are treated as trusted by downstream consumers Third-party SaaS service compromise — Managed services integrated into the build and release path (code quality tools, security scanners, deployment orchestrators) compromised to inject malicious payloads or exfiltrate source code and secrets Ephemeral runner exploitation — Exploitation of shared or insufficiently isolated CI/CD runners to access secrets, build artefacts, or source code from other projects sharing the same infrastructureConsequences Silent injection of malicious code into production — Compromised build tools can modify artefacts during compilation, packaging, or deployment without any trace in source control, making detection through code review or source-level scanning impossible. Compromise of the trust chain — If signing keys or attestation services are compromised, the organisation loses the ability to distinguish legitimate artefacts from tampered ones, undermining the entire basis for deployment trust decisions. Cross-project blast radius — Build infrastructure typically serves multiple projects and teams. A single compromised build agent, shared runner, or CI/CD platform can affect every project that uses it. Credential theft enabling further attacks — CI/CD environments routinely hold deployment credentials, cloud provider keys, and service tokens. Exfiltration of these credentials enables attackers to directly access production environments (ri-9) or deploy unauthorised changes (ri-8). Regulatory and compliance exposure — Regulators expect organisations to demonstrate the integrity of their software delivery pipeline. Inability to assure that build tools and services have not been tampered with undermines compliance with DORA Article 7, PCI DSS Requirement 6, SOX Section 404, and NIST supply chain risk management frameworks. Extended dwell time — Build toolchain compromises are particularly difficult to detect because the malicious activity occurs within trusted infrastructure and may produce artefacts that pass all standard security checks.Links
Regulatory and Compliance
2 risksInsider Threat
Authorized personnel (developers, contractors, administrators, or other trusted users) with legitimate access to source code repositories, development environments, production systems, or sensitive data may intentionally or unintentionally compromise the confidentiality, integrity, or availability of software assets.DescriptionInsider Threat includes risks of malicious code injection, unauthorized data exfiltration, credential misuse, sabotage of build/deployment pipelines, or negligent security practices that expose systems to exploitation. Additionally, insider threat encompasses scenarios where external attackers have compromised the credentials of legitimate users, enabling them to conduct attacks while masquerading as trusted personnel with valid access. The trusted position and technical knowledge of insiders—or attackers leveraging insider credentials—makes detection difficult and potential impact significant. Malicious code injection - Inserting backdoors, vulnerabilities, or malicious logic into applications or infrastructure Compromised credentials - Attackers using stolen or phished developer/admin credentials to access systems and data Data exfiltration - Stealing source code, intellectual property, customer data, or sensitive business information CI/CD pipeline manipulation - Tampering with build processes, deployment pipelines, or supply chain components to inject malicious code Cloud/infrastructure misconfiguration - Accidentally or intentionally exposing databases, storage, or services to unauthorized accessConsequencesThe consequences of an insider threat materializing for a financial institution can be severe: Direct Financial Losses: Fraudulent transactions, theft of funds, unauthorized wire transfers, or manipulation of accounts can result in immediate monetary losses to the institution and its customers. Breach of Data Privacy Regulations: Unauthorized access to or exfiltration of customer PII can lead to significant fines under regulations like GDPR, CCPA, and GLBA, alongside mandated breach notifications and regulatory scrutiny. Violation of Financial Regulations: Insider actions compromising system integrity, audit trails, or customer data can breach banking regulations (e.g., SOX, PCI DSS, Basel III) and trigger enforcement actions from regulatory bodies. Reputational Damage: Public disclosure of insider attacks—particularly those involving customer funds or data—can severely erode customer trust, leading to account closures, deposit flight, and long-term brand damage. Operational Disruption: Sabotage of critical banking systems, payment processing infrastructure, or core applications can halt operations, impacting customer service and transaction processing capabilities. Loss of Competitive Advantage: Theft of proprietary trading algorithms, risk models, customer insights, or strategic plans can benefit competitors and undermine market position. Legal Liabilities: The institution may face lawsuits from affected customers, shareholders, or partners, as well as potential criminal investigations if insider actions involve fraud or data breaches. Does this capture the right scope and tone for your risk register?Links FFIEC IT Handbook Scalable Extraction of Training Data from (Production) Language Models
Audit and Compliance Evidence Failure
An organisation cannot produce, on demand and for any point in time within the required retention period, the records that demonstrate its SDLC governance operated as intended — including policy approvals, control design decisions, risk acceptance sign-offs, exception management, security design reviews, test evidence, and release gate outcomes — creating exposure to regulatory enforcement, failed audits, and loss of certifications essential to operating in financial services.DescriptionThis risk concerns the evidentiary problem: whether the organisation can prove what its SDLC governance did and when. It is distinct from configuration drift (ri-7), which concerns divergence between declared and actual system state, and from unauthorised change (ri-8), which concerns whether individual changes were properly approved. Evidence failure can exist even when controls are well-designed and consistently applied, if the records that attest to their operation are unavailable, incomplete, cannot withstand scrutiny, or cannot be tied to specific points in time.SDLC governance generates a broad set of artefacts: architectural decision records, threat models, risk assessments, control design documentation, waiver and exception records, change advisory board decisions, security review findings, penetration test results and remediation traces, release gate approvals, and control ownership assignments. The inability to produce any of these when requested by a regulator, auditor, or enterprise customer constitutes an evidence failure regardless of whether the underlying activity took place. Inability to reconstruct SDLC change history within audit timelines — The organisation cannot produce, when requested, a verifiable record linking code changes to their corresponding reviews, approvals, and deployment decisions across the period under examination Inability to demonstrate continuous control operation — Evidence covers only point-in-time snapshots (audit preparation periods, certification renewals) and does not demonstrate that controls operated consistently across the full audit period Evidence that fails integrity or authenticity scrutiny — Records presented as evidence can be shown to have been created, modified, or deleted after the fact, or cannot be attributed to a specific actor with a trustworthy timestamp Broken traceability between governance decisions and the artefacts they govern — Approval records, review outcomes, and risk assessments exist but cannot be linked to the specific code changes, releases, or deployments they relate to, preventing end-to-end reconstruction of the control chain Records do not survive their required retention period — SDLC governance artefacts are deleted, overwritten, or become inaccessible before the end of the regulatory retention window, leaving the organisation unable to respond to examination requests covering prior periods Inability to demonstrate control ownership and decision accountability at a point in time — The organisation cannot show who owned a control, who was accountable for a governance decision, or who authorised an exception at the time the activity occurredConsequences Regulatory enforcement actions — Banking and financial regulators treat unsubstantiated controls as absent controls. Inability to produce SDLC governance evidence during an examination can result in formal enforcement actions, mandatory remediation programmes, restrictions on technology change activity, and heightened supervisory scrutiny. SOX Section 404 material weakness findings — Auditors assessing internal controls over financial reporting may classify insufficient SDLC evidence as a material weakness or significant deficiency, requiring disclosure and remediation with direct impact on financial reporting timelines. PCI DSS compliance failure — Requirements covering secure development (Req 6) and targeted risk analysis (Req 12.3) require documented evidence of control operation. Inability to produce this evidence during a QSA assessment can result in loss of attestation of compliance. DORA Article 6 non-compliance — The Digital Operational Resilience Act requires financial entities to maintain comprehensive ICT risk management frameworks with demonstrable governance. Evidence gaps in SDLC controls constitute a gap in the ICT risk management documentation DORA mandates. GLBA Safeguards Rule exposure — Financial institutions subject to the Gramm-Leach-Bliley Act must demonstrate that their information security programme — including software development controls — is documented and operating effectively. SOC 2 Type II report qualifications — Service organisations require evidence of continuous control operation across the entire examination period. Incomplete or point-in-time-only evidence results in qualified opinions or exceptions that damage commercial relationships with enterprise customers. Failed customer and partner audits — Enterprise customers in regulated industries increasingly require SDLC governance evidence as part of vendor due diligence and ongoing third-party risk management. Evidence failures result in lost contracts, exclusion from procurement processes, and damage to commercial reputation. Increased cost of compliance — Organisations that cannot produce evidence on demand face extended audit cycles, higher audit fees, and resource-intensive evidence reconstruction efforts that divert engineering and governance capacity from productive work.Links
Business
1 risksBusiness Reputation Risk from Non-Approved Software Version Releases
Software versions that have not completed the required approval, validation, or governance process but are released to production, might cause customer-facing defects, regulatory non-compliance, or security vulnerabilities that erode market confidence, damage the institution’s reputation, and trigger stakeholder backlash.Additionally, versions that are misaligned with product direction or has features that conflict with the companies broader strategic goals or marketing messages might harm strategic goals.As a result, for companies that are publicly traded in the US (or falls under global equivalents like UK SOX), a formal version release approval process is one of the most critical elements of a Sarbanes-Oxley (SOX) audit: SOC 2 Type II - CC8.1 (Change Management) - Requires organizations to authorize, design, develop, test, approval, and implement system changes to prevent unauthorized modifications and maintain integrity.DescriptionFinancial institutions operate under strict change management and release governance frameworks that require software versions to pass defined quality gates, risk assessments, security reviews, and approval checkpoints before reaching production. When software is released outside this approval process—whether through pipeline misconfigurations, governance bypasses, emergency shortcuts, or deliberate circumvention—the resulting production incidents expose the institution to reputational harm that can outlast the technical failure itself.Non-approved releases may carry untested changes, unresolved vulnerabilities, broken integrations, or incomplete compliance controls. Even when the technical impact is contained quickly, the public disclosure of a release governance failure signals to customers, regulators, and counterparties that the institution’s internal controls cannot be relied upon. In markets where trust is foundational, this signal alone carries lasting commercial consequences. Release pipeline bypass — Changes deployed to production without passing mandatory approval gates, peer review, or security scanning due to misconfigured pipelines or deliberate shortcuts Emergency hotfix without governance — Urgent fixes applied directly to production outside normal change management, introducing untested code that causes new defects or exposes existing vulnerabilities Incorrect version promotion — A build artefact from a non-approved branch or an earlier rejected release candidate is accidentally promoted to production, carrying known defects or previously rejected functionality Shadow releases and feature flags — Partial feature activations or configuration changes that effectively constitute a release are made without formal approval, bypassing governance controls Rollback to a non-approved state — Incident response rollbacks that restore a production version that predates the current approval baseline, reintroducing previously remediated defects or compliance gapsConsequences Customer-Facing Service Disruption: Non-approved releases carrying defects or incompatible changes can cause transaction failures, incorrect account balances, broken payment flows, or application unavailability, directly affecting customers and triggering complaints, churn, and media coverage. Regulatory Censure and Enforcement Action: Financial regulators (e.g., FCA, OCC, FINRA, ECB) require evidence of robust change management. Release of non-approved software signals a breakdown in internal controls and can result in formal findings, remediation orders, increased supervisory scrutiny, or fines. Erosion of Customer and Counterparty Trust: Public incidents attributed to inadequate release governance—particularly those involving financial errors or data exposure—damage the institution’s reputation with retail customers, institutional counterparties, and rating agencies, with effects that persist long after the technical incident is resolved. Reputational Contagion Across Product Lines: A high-profile release failure in one product or channel can cast doubt on the reliability of the institution’s entire technology estate, affecting products that were not involved in the incident. Internal Confidence and Talent Impact: Sustained reputational damage and visible governance failures can affect the institution’s ability to attract and retain technology talent, particularly in competitive engineering markets where employer brand matters. Legal Liability: Customers or counterparties suffering financial losses as a result of a non-approved release may pursue civil claims, compounding reputational damage with litigation costs and adverse judgments. Links
Mitigation Catalogue
Discover preventative and detective controls to mitigate identified risks in your AI systems.
Preventative
18 mitigationsContent Addressable Identities
Software artifacts are identified by cryptographic hashes of their contents, ensuring that any change to an artifact produces a different identity and making tampering immediately detectable.DescriptionHigh-security environments require a tamper-proof identity scheme for software artifacts (e.g. compiled binaries, container images, JAR files, npm packages, Helm charts, configuration bundles). Content addressable identification uses cryptographic hashing (e.g., SHA-256) to derive an artifact’s identity directly from its contents. Unlike mutable labels such as version tags or filenames, these identities are immutable: even a single-byte change produces a completely different hash. This provides the foundation for verifiable integrity of binaries, containers, packages, and other deliverables throughout the software development lifecycle.Human-readable identifiers (semantic versions, branch names, commit references) remain useful for navigation and convenience but must never be relied upon for security or compliance verification.Requirements Every software artifact MUST be identified by a cryptographic hash (SHA-256 or stronger) of its contents Any modification to an artifact MUST produce a completely different identity Content addressable identities MUST be immutable and cannot be forged or reassigned to different content All systems that store, transfer, or deploy artifacts MUST reference them by their cryptographic identityExamples & Commentary Generate SHA-256 hashes for all build outputs including container images, compiled binaries, archives, and packages Configure container registries and artifact repositories to use content-addressable storage (e.g., Docker content trust, OCI image digests) CI/CD pipelines should propagate cryptographic identities rather than mutable tags when referencing artifacts across stages Implement verification checks at deployment boundaries that confirm the cryptographic identity of an artifact before allowing it to proceed Store artifact hashes in a secure, append-only record that serves as the source of truth for artifact identity
Software Artifact Provenance
Internally built software artifacts have known and verifiable provenance, establishing a documented chain of custody from source code commit through build and into deployment.DescriptionSoftware artifact provenance answers the question “where did this artifact come from?” for any artifact at any time. Provenance records are created at build time and capture the source commit, repository state, build environment details, build log references, and the resulting artifact identity. These records are immutable once written and stored in a tamper-evident system that prevents retroactive modification.By linking the cryptographic identity of an artifact (from content addressable identities) to its source and build metadata, software artifact provenance ensures that only artifacts built from known source code through an authorised build process.Requirements Each artifact MUST be traceable back to a specific source code commit, build process, and build environment Provenance records MUST be created at build time and be immutable once written Provenance records MUST include: Cryptographic hash of the output artifact Source commit reference Sufficient build environment context to support traceability, for example: Build system URL Build log reference Builder identity Build tool versions Timestamp Examples & Commentary No artifact should be deployed to production without a corresponding provenance record Use a dedicated provenance store or attestation service to maintain build records independently of the CI/CD system Implement deployment gates that verify an artifact has a valid provenance record before allowing promotion to production environments Periodically audit provenance records against running deployments to confirm that all production artifacts have known origins Distinguish between human-friendly identifiers (semantic versioning, commit references) for navigation and cryptographic hashes for security and compliance purposes Where human-readable identifiers are used, they should ideally be mapped to their corresponding cryptographic identities in an immutable way, such that the mapping itself cannot be altered or reassigned after the fact
Requirements Management
Ensures requirements are maintained in an approved repository and that its correct usage is periodically attested.Map to related risks• Risk 1: Ungoverned or inconsistent requirements repositories• Risk 2: Requirements progressing without minimum readinessDescriptionThis control establishes a single, governed source of truth for requirements and requires periodic confirmation that the repository is actively used and that requirements meet agreed readiness criteria.Requirements (Expectations)• An approved requirements repository is designated for the application• Usage of the repository is periodically attested• Requirements meet an agreed Definition of Ready before developmentExamplesThe control supports a “shift left” approach by embedding quality and clarity at the point requirements enter development, rather than relying on downstream inspection.Links to external standards for controls• ISO/IEC 27001 – information integrity and governance• IREB / IIBA requirements management standardsControl 2: Requirements for Release – Reviewed and Agreed (XXXX-01068)
Vulnerability Scanning - SAST
Static Application Security Testing (SAST) analyses application source code, bytecode, or binaries to identify security vulnerabilities, coding flaws, and insecure patterns before software is deployed.DescriptionStatic Application Security Testing (SAST) examines an application’s source code or compiled artefacts without executing the program. By analysing code paths, data flows, and control flows, SAST tools detect categories of vulnerability such as injection flaws, buffer overflows, hard-coded secrets, insecure cryptographic usage, and race conditions. Because SAST operates on the code itself, it can identify issues very early in the development lifecycle — often at the point a developer opens a pull request — making remediation faster and cheaper than finding defects in later stages. In regulated financial services environments, embedding SAST into the CI/CD pipeline provides continuous assurance that code meets secure coding standards and supports audit evidence of proactive security testing.Requirements SAST MUST be performed against application source code as part of the software development lifecycle SAST MUST be automated — manual-only code analysis is not sufficient as a primary control The point(s) at which SAST scans are executed MUST be defined based on development practices, risk profile, and pipeline architecture SAST scans MUST cover all languages and frameworks in active use across the organisation’s application portfolio Findings MUST be classified by severity (e.g., Critical, High, Medium, Low) using an industry-recognised standard such as CWE or CVSS A baseline ruleset MUST be maintained, aligned with recognised secure coding standards (e.g., OWASP Top 10, CWE Top 25, CERT Secure Coding Standards), and reviewed at least annually False positives MUST be triaged, documented, and suppressed through an auditable process — blanket suppression of finding categories is not permitted SAST results, including findings, remediation actions, and exceptions, MUST be retained in accordance with the organisation’s record retention policyExamples & Commentary Pull Request Gating: Configure SAST to run as a required status check on pull requests. Developers receive immediate feedback on security issues in their own code before review, reducing the burden on reviewers and shortening remediation cycles Incremental vs Full Scans: Use incremental (diff-only) scans on pull requests for fast feedback, complemented by periodic full repository scans to catch issues that span multiple files or emerge from cumulative changes Custom Rules: Supplement vendor-provided rulesets with organisation-specific rules that encode internal security requirements (e.g., prohibiting use of deprecated internal libraries, enforcing approved cryptographic primitives) Developer Enablement: Provide IDE plugins or pre-commit hooks so developers can catch common issues locally before pushing code, shifting security further left Metrics & Reporting: Track mean-time-to-remediate, finding density per repository, and false positive rates to measure programme effectiveness and identify teams or codebases that need additional supportLinks OWASP Source Code Analysis Tools OWASP Top 10 CWE Top 25 Most Dangerous Software Weaknesses NIST SP 800-53r5 SA-11: Developer Testing and Evaluation CERT Secure Coding Standards FFIEC IT Handbook - Information Security
Vulnerability Scanning - DAST
Dynamic Application Security Testing (DAST) tests running applications by simulating real-world attacks against exposed interfaces to identify exploitable vulnerabilities that cannot be detected through source code analysis alone.DescriptionDynamic Application Security Testing (DAST) analyses applications in their running state by sending crafted requests to exposed endpoints and observing the responses. Unlike SAST, which examines source code, DAST tests the application as an attacker would — through its HTTP interfaces, APIs, and authentication flows — making it effective at finding runtime and configuration vulnerabilities such as injection flaws, broken authentication, security misconfigurations, and sensitive data exposure. DAST is language- and framework-agnostic because it operates against the deployed artefact rather than the code. In regulated financial services environments, DAST provides evidence that applications have been tested against real attack scenarios prior to production release and on an ongoing basis thereafter.Requirements DAST MUST be performed against web applications and APIs as part of the software development lifecycle DAST MUST be automated — manual-only dynamic testing is not sufficient as a primary control The frequency and trigger points for DAST scans MUST be defined based on release cadence, application risk profile, and deployment model DAST tooling MUST be configured to test against the OWASP Top 10 vulnerability categories at a minimum Authenticated scanning MUST be performed where applicable to test functionality behind login flows, ensuring coverage of authorisation and session management vulnerabilities API-specific scanning MUST be performed for all REST, GraphQL, and other API endpoints, using OpenAPI specifications or equivalent API definitions where available DAST scans MUST be executed in environments that do not compromise production data integrity — production-equivalent staging environments are preferred DAST results, including findings, remediation actions, and exceptions, MUST be retained in accordance with the organisation’s record retention policyExamples & Commentary Pipeline Integration: Trigger DAST scans automatically after deployment to a staging environment as part of the CI/CD pipeline. Gate promotion to production on scan results Authenticated vs Unauthenticated Scans: Run both unauthenticated scans (simulating an external attacker) and authenticated scans (simulating a logged-in user) to maximise coverage of the application’s attack surface API Contract Testing: Feed OpenAPI/Swagger specifications into DAST tooling to ensure all documented endpoints are tested, including edge cases such as malformed inputs, missing authentication headers, and parameter tampering Crawl Depth & Coverage: Configure scan policies to adequately crawl modern single-page applications (SPAs) and JavaScript-heavy frontends, which may require headless browser-based scanning capabilities Environment Considerations: DAST generates real traffic and may modify application state. Use dedicated staging environments with synthetic data, and ensure scans do not trigger denial-of-service conditions or corrupt shared test data Complementing SAST: DAST and SAST are complementary — SAST finds issues in code that may not be reachable at runtime, while DAST finds runtime and configuration issues invisible to static analysis. Both should be used together for defence in depthLinks OWASP DAST Tools OWASP Top 10 OWASP Web Security Testing Guide OWASP API Security Top 10 NIST SP 800-53r5 CA-8: Penetration Testing FFIEC IT Handbook - Information Security
Vulnerability Scanning - Dependencies
Dependency and vulnerability scanning identifies known vulnerabilities (CVEs) in third-party dependencies, libraries, container images, and other software components before they are deployed to production.DescriptionModern software relies heavily on open-source and third-party components, which may contain publicly disclosed vulnerabilities (CVEs) or be subject to supply chain compromise. Dependency and vulnerability scanning provides automated, continuous analysis of all software components to detect known security flaws, outdated packages, and license compliance issues. In regulated financial services environments, unpatched vulnerabilities in production systems represent a material operational and compliance risk. Dependency scanning maintains visibility into the software supply chain, enabling rapid response when new vulnerabilities are disclosed.Requirements Application repositories MUST be scanned for known vulnerabilities in direct and transitive dependencies as part of the software development lifecycle Dependency scanning MUST be automated — manual-only dependency review is not sufficient as a primary control The point(s) and frequency at which dependency scans are executed MUST be defined based on development practices, risk profile, and pipeline architecture Container images MUST be scanned for operating system and application-level vulnerabilities as part of the build and deployment process Scanning tools MUST be configured to check for vulnerabilities in all relevant ecosystems used by the organisation (e.g., npm, PyPI, Maven, NuGet, Go modules, system packages) Vulnerability scanning results MUST be classified by severity and tracked to resolution A documented exception and risk-acceptance process MUST exist for vulnerabilities that cannot be immediately remediated, with appropriate approvals and time-bound waivers Audit logs of all scan results, remediation actions, and exceptions MUST be retained in accordance with the organisation’s record retention policyExamples & Commentary CI/CD Integration: Configure Software Composition Analysis (SCA) tooling to run on every pull request. Builds targeting production branches should fail if critical or high severity CVEs are detected without an approved exception Scheduled Scanning: Even without code changes, new CVEs are disclosed daily. Recurring scans of the default branch and deployed artefacts ensure newly published vulnerabilities are detected against existing codebases Container Scanning: Scan base images and final application images in the container registry. Alert on images with known vulnerabilities and enforce policies that prevent deployment of non-compliant images Dependency Pinning & Lock Files: Ensure all projects use lock files (e.g., package-lock.json, go.sum, Pipfile.lock) to guarantee reproducible builds and prevent silent dependency changes Triage & Prioritisation: Not all CVEs are equally exploitable. Organisations should consider reachability analysis and environmental context when prioritising remediation efforts, but must still track all findings to closure Complementing Component Inventory: This control works alongside Component Inventory (SDLC-PREV-009), which provides the SBOM. Dependency scanning uses the inventory to detect which components are affected when new vulnerabilities are disclosedLinks NIST SP 800-53r5 RA-5: Vulnerability Monitoring and Scanning OWASP Dependency-Check CycloneDX SBOM Standard SPDX SBOM Standard NIST Cybersecurity Supply Chain Risk Management (C-SCRM) FFIEC IT Handbook - Information Security
Version Control
Software and configuration must be stored winth an approved version control system.DescriptionVersion control is required to maintain a history of all software and configuration changes across all releases. It provides traceability of who made changes and when, establishing the provenance of software over time.The control establishes verifiable evidence of the state of source code or configuration at the time a release was created. This is important not only for identifying who made changes, but also for understanding what functionality existed at a given point in time — enabling diagnosis of software behaviour weeks, months, or even years after it was originally built, tested, and deployed.Version control is also integral to ensuring that the software being built and tested is the same software being deployed, by tracking the specific commit or version and providing a reference for traceability.RequirementsIn order for a version control system to be effective, it must provide the following properties when used for storing software and configuration. Immutable History — The version control system must preserve the integrity of history to prevent tampering and maintain the audit trail. Verified Committers — The version control system must record the author of each change. Techniques such as commit signing could be employed to demonstrate this. Retention — History must be maintained for the lifetime of the software or in alignment with applicable retention requirements. Access Control — The version control system must support access control and should be configured appropriately.ExamplesGit is the most widely adopted distributed version control system and is the de facto standard for software development in regulated and non-regulated environments alike. Immutable History — Every commit is identified by a cryptographic SHA hash derived from its content and its parent commits, making silent tampering detectable. Verified Committers — Git supports GPG and SSH commit signing natively. Hosting platforms such as GitHub and GitLab can be configured to require signed commits on protected branches. Access Control — Enforced at the hosting platform level via branch protection rules, required reviewers, and role-based repository permissions.Subversion (SVN) is a centralised version control system still found in some legacy financial services environments. Immutable History — SVN maintains a sequential, server-side revision history. Once committed, revisions cannot be altered without administrator access to the repository backend. Verified Committers — SVN records the authenticated username against each commit. Commit signing is not natively supported; identity relies on server authentication (e.g. LDAP, Kerberos). Access Control — Controlled server-side via path-based authorisation, allowing fine-grained read/write permissions per directory or branch.Links About commit signature verification — GitHub Signing commits — GitHub
Component Inventory
Component inventory provides visibility and traceability and enables fast response by maintaining an accurate, machine-readable record of what is actually shipped in each artifact.DescriptionComponent inventory is the practice of identifying and cataloguing all third-party components (libraries, packages, modules) that are included in a software artifact — i.e. what is actually shipped. This includes direct and transitive dependencies. The output is typically a Software Bill of Materials (SBOM) in a standard format such as SPDX or CycloneDX.The inventory provides visibility and traceability and enables fast response: you know what you ship (visibility), you can trace components to artifacts (traceability), and when a vulnerability is disclosed, a license concern arises, or another issue surfaces, you can query the inventory to see which artifacts are affected and respond quickly. Additional analysis (e.g. vulnerability scanning, license compliance) adds further value by enabling prevention before issues reach production. Extraction from the actual artifact (container image, binary, filesystem) rather than from declarations alone enables detection of discrepancies between what is declared and what is present.Requirements The output MUST be a structured, machine-readable SBOM (e.g. SPDX or CycloneDX). The inventory MUST include direct and transitive dependencies with version and provenance information where available. The SBOM MUST be produced for each releasable artifact.Examples & Commentary No releasable artifact should be deployed without a corresponding component inventory (SBOM); this complements Software Artifact Provenance (SDLC-PREV-003), which establishes build-level provenance, by providing component-level visibility and traceability. Automated extraction from the artifact plus a machine-readable manifest (SBOM) together provide full coverage. Extraction (e.g. automated binary scan) can be compared to declared dependencies to identify discrepancies; the manifest records what is in each artifact so you can query it when issues arise (e.g. which artifacts contain a given component). When a new CVE is published (e.g. Log4Shell), query the inventory across all artifacts to identify which contain the affected component and version; without an inventory, manual inspection or waiting for a scan would be required — with SBOMs, remediation can be prioritised and executed within hours. Use the inventory for license compliance: an SBOM listing components with their licenses allows automated checks before deployment; any artifact containing a prohibited license can be flagged or blocked. Implement deployment gates that verify an artifact has a valid SBOM before allowing promotion to production; the SBOM can be stored alongside provenance records (SDLC-PREV-003) or in a dedicated SBOM store. Tools exist to extract components from container images or filesystems, or to generate SBOMs from the build; the SBOM is the input for vulnerability scanning and license compliance checks. The SBOM MAY include recommended elements (e.g. component name, version, PURL, CPE, license info, file hashes) to support faster response and downstream analysis.Links NTIA Minimum Elements for an SBOM OWASP SCVS V2: SBOM Requirements CycloneDX Specification SPDX Specification CISA SBOM Guide CRA Regulation (EU) 2024/2847 (Annex I, vulnerability handling) NIST SSDF SP 800-218 (PS.3.2, RV.1.2)
Secret Detection
Secret detection identifies hardcoded credentials, API keys, tokens, and passwords in source code, configuration files, and version control history, preventing credential exposure and unauthorised access.DescriptionSecrets — such as API keys, database passwords, private keys, tokens, and service account credentials — are frequently committed to source code repositories by accident. Once a secret is pushed to a repository, it may be exposed to anyone with access to the codebase, and if the repository is public or is later compromised, the secret can be exploited by malicious actors. Even in private repositories, secrets in version control history persist indefinitely unless explicitly purged. Secret detection tooling scans source code, configuration files, environment definitions, and commit history to identify credentials before they are merged or as soon as possible after exposure. In regulated financial services environments, exposed credentials represent a direct and material security risk, and organisations must demonstrate proactive controls to prevent and respond to credential leakage.Requirements Secret detection MUST be performed against source code and configuration as part of the software development lifecycle Secret detection MUST be automated — manual-only review is not sufficient as a primary control The point(s) in the development workflow at which secret detection scans are executed MUST be defined based on development practices, risk profile, and pipeline architecture Pre-commit hooks or equivalent client-side checks SHOULD be provided to developers to catch secrets before they are pushed to the remote repository Scanning MUST cover all file types and configuration formats in the repository, including infrastructure-as-code templates, CI/CD pipeline definitions, and environment files Detection rulesets MUST cover, at minimum, common secret types: API keys, private keys, database connection strings, OAuth tokens, cloud provider credentials, and service account keys When a secret is detected, the affected credential MUST be rotated and the secret removed from the codebase. A response process for detected secrets MUST be defined and enforced, appropriate to the organisation’s risk posture When a previously committed secret is discovered in version control history, the affected credential MUST be rotated immediately and the secret SHOULD be purged from history where feasible An allowlist/exclusion process for false positives MUST be maintained, with documented justification and periodic review Secret detection results MUST be retained in accordance with the organisation’s record retention policyExamples & Commentary Pre-commit Prevention: Deploy pre-commit hooks (e.g., using frameworks like pre-commit with secret detection plugins) so that secrets are caught on the developer’s machine before they ever reach the repository. This is the most effective point of intervention CI Pipeline Scanning: Run secret detection as a required status check on every pull request. If a secret is found, fail the check and provide clear guidance to the developer on how to remediate (remove the secret, rotate the credential, use a secrets manager) Historical Scanning: Periodically scan the full git history of repositories, not just the latest commit. Secrets committed months ago and subsequently deleted from the working tree may still be present in history and exploitable Custom Patterns: Supplement default detection rules with organisation-specific patterns for internal credential formats, proprietary API key prefixes, or internal service tokens Secrets Management Integration: Pair this control with a secrets management solution (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and enforce that applications retrieve secrets at runtime rather than embedding them in code or configuration Incident Response: Define a clear process for when a secret is found: who is notified, what is the rotation timeline, and how is the exposure assessed. Treat any secret found in a public repository as compromised and rotate immediatelyLinks OWASP Secrets Management Cheat Sheet NIST SP 800-53r5 IA-5: Authenticator Management CWE-798: Use of Hard-coded Credentials CWE-312: Cleartext Storage of Sensitive Information FFIEC IT Handbook - Information Security
Vulnerability Remediation SLAs
Vulnerability Remediation SLAs establish severity-based timelines for addressing security findings, ensuring that vulnerabilities are tracked to resolution within agreed timeframes.DescriptionIdentifying vulnerabilities is only effective if findings are remediated in a timely manner. Without defined remediation timelines, vulnerability backlogs grow indefinitely, and critical issues may persist in production for months. Vulnerability Remediation SLAs establish mandatory timelines for addressing findings based on their severity, create accountability for remediation, and provide a framework for exceptions when immediate remediation is not feasible. This control applies to findings regardless of how they were identified, providing a consistent remediation framework across the organisation.Requirements Remediation SLAs MUST be defined for security vulnerability findings, with timelines differentiated by severity level Remediation SLA timelines MUST be documented and approved, reflecting the organisation’s risk appetite and regulatory obligations SLA compliance MUST be tracked and reported to relevant stakeholders on a regular cadence A documented exception and risk-acceptance process MUST exist for vulnerabilities that cannot be remediated within the defined SLA Remediation SLA definitions, compliance metrics, and exception records MUST be retained in accordance with the organisation’s record retention policyExamples & Commentary Severity Classification: Use an industry-recognised standard such as CVSS for severity scoring, supplemented by environmental context. A critical CVSS score in an internet-facing application may warrant faster remediation than the same score in an isolated internal tool SLA Clock Start: Define clearly when the SLA clock begins — typically when the finding is first reported by a scanning tool, not when a developer triages it. This prevents delays from slow triage processes Exception Governance: Establish a lightweight but auditable exception process. For example, a developer can request a 30-day waiver for a high-severity finding with justification and compensating controls, approved by the security team. The waiver is time-bound and automatically escalates if not resolved Dashboard & Visibility: Maintain a vulnerability dashboard showing open findings by severity, SLA status (on-track, at-risk, overdue), and trends over time. Make this visible to engineering teams and leadership to drive accountability Relationship to Deployment Gating: Remediation SLAs define when a finding must be fixed. Deployment Gating (SDLC-PREV-012) defines whether an application with outstanding findings can be deployed. Together they provide both a timeline for remediation and a hard stop when that timeline is not metLinks NIST SP 800-53r5 SI-2: Flaw Remediation NIST SP 800-53r5 CA-5: Plan of Action and Milestones FIRST CVSS v4.0 Specification CISA Known Exploited Vulnerabilities Catalog FFIEC IT Handbook - Information Security
Deployment Gating
Deployment gating blocks promotion of software to the target environment when defined control criteria are not met.DescriptionDeployment gating enforces policy-based decisions at the point of deployment to ensure that only software meeting defined control criteria is promoted to production. Gates evaluate the posture of an artefact against the organisation’s defined policies and block deployment when criteria are not met. Without deployment gates, other controls in the framework are advisory only, and non-compliant software may reach the target environment despite known issues. In regulated financial services environments, deployment gating provides auditable evidence that organisational policy was enforced at every release.Requirements Deployment gating policies MUST be defined to specify which conditions block deployment, based on the organisation’s risk appetite and regulatory requirements Gating policies MUST be configurable per application or service to allow organisations to tailor risk thresholds (e.g., stricter policies for internet-facing applications, adjusted thresholds for internal tools) A documented override and emergency deployment process MUST exist for situations where deployment is critical despite unmet gate conditions. Overrides MUST require approval from an appropriate authority, include documented justification, and be time-bound Overrides MUST be logged and auditable, including who approved, the justification, and the conditions that were bypassed Gate evaluation results — including pass/fail status, which checks were evaluated, and any overrides — MUST be retained as part of the deployment record Gating policies MUST be reviewed and updated at least annually, or when significant changes to the threat landscape, regulatory requirements, or technology stack occurExamples & Commentary Policy Examples: An organisation might define the following deployment gates: no new critical or high SAST findings; no critical CVEs in dependencies without an approved waiver; DAST scan completed within the last 14 days; no secrets detected in the codebase. The specific policies will vary by organisation and risk appetite Pipeline Enforcement: Implement gates as required steps in the CI/CD pipeline. For example, a deployment job queries the vulnerability management platform for the artefact’s security posture and proceeds only if all gate conditions are satisfied Graduated Policies: Apply different gate strictness by environment and application criticality. A development environment might allow deployment with medium findings, while production for a customer-facing application blocks on anything high or above Emergency Overrides: Define an emergency deployment process for genuinely urgent situations (e.g., a critical production outage fix). The override should require real-time approval from a security lead or on-call manager, be time-limited, and automatically create a follow-up ticket to address the bypassed condition Visibility & Feedback: When a deployment is blocked, provide clear and actionable feedback to the engineering team: which gate failed, what findings caused the failure, and what actions are needed to proceed. Poor feedback loops lead to frustration and incentivise workarounds Relationship to Remediation SLAs: Deployment gating works hand-in-hand with Remediation SLAs (SDLC-PREV-011). SLAs define when findings must be remediated; gates enforce that deployments cannot proceed when those timelines are breached. For example, a high-severity SAST finding with a 7-day SLA may not block deployment on day 1, but will block it on day 8 if unresolvedLinks NIST SP 800-53r5 CM-3: Configuration Change Control NIST SP 800-53r5 CM-4: Impact Analyses NIST SP 800-53r5 CA-2: Control Assessments OWASP DevSecOps Guideline NIST SSDF SP 800-218 FFIEC IT Handbook - Information Security
System Inventory
Organizations must maintain a current, accurate inventory of all systems operating in production. Each inventory record must capture system ownership — including designation of a system manager who is an active employee — along with system criticality classification and data classification. The inventory must be linked to the developer toolchain and SDLC systems and it must be reviewed and updated on a defined cadence and upon any material change.DescriptionA well-governed system inventory is foundational to an organization’s risk management, compliance, and operational resilience posture. Financial services organizations operate complex, interconnected technology estates spanning on-premises infrastructure, cloud platforms, third-party hosted services, and internally developed applications.Without a reliable and current inventory, organizations cannot consistently apply security controls, assess blast radius during incidents, fulfill regulatory obligations, or make informed decisions about system decommissioning and lifecycle transitions.This control establishes the minimum requirements for maintaining a system inventory that is accurate, ownership-attributed, and enriched with the metadata necessary to support downstream risk and compliance processes. The inventory serves as a system of record that feeds into change management, access control, vulnerability management, business continuity planning, and regulatory reporting workflows.Requirements Inventory ScopeThe inventory must include all systems operating in production, defined as any system that:Supports a business process, customer-facing service, or internal operational function;Stores, processes, or transmits organizational or customer data; orIntegrates with or has a trust relationship to another in-scope system. Inventory AttributesEach inventory record must capture a set of attributes such as: System Name, System ID, System Description, System Manager, System Criticality Tier classification, Data Classification, Lifecycle Status (Active / Sunset Planned / Decommissioned) Inventory MaintenanceThe inventory must be reviewed in its entirety no less than annually, with individual records updated within 30 days of any material change (e.g., new system launch, change of System Manager, re-classification, decommission).A new system must be added to the inventory prior to or concurrent with its promotion to production. Systems must not enter production without an assigned System Manager and completed classification attributes.When a System Manager separates from the organization or changes roles, an updated System Manager must be designated and reflected in the inventory within 5 business days. System Criticality Classification - for example: Tier 1 - Business Critical, Tier 2 - High Criticality, Tier 3 - Medium Criticality, Tier 4 - Low Criticality. Data Classification - for example Restricted, Confidential, Internal, Public Linkage to Developer Toolchain and SDLC Systems Each inventory record must be traceable to its corresponding source code repository (e.g., GitLab, GitHub), CI/CD pipeline configuration, and artifact registry, enabling a continuous chain of custody from code commit through production deployment. This linkage ensures that changes to a production system are always attributable to an inventoried, ownership-attributed entity, and that pipeline-enforced controls — such as security scanning, compliance gates, and deployment policies — can be scoped and validated against a known system baseline. Tooling and AccessThe inventory must be maintained in a centralized, access-controlled system of record.Read access should be broadly available to authorized internal stakeholders. Write access must be controlled and auditable.The inventory system must support export and reporting capabilities to facilitate governance reviews and audit requestsExamples & CommentaryExample 1 — New System OnboardingA development team completes build and testing of a new customer-facing loan origination portal and prepares for production deployment. Prior to the production release, the team’s technology lead is designated as System Manager and the system is registered in the inventory with a criticality of Tier 1 (Mission Critical) — as it directly supports a revenue-generating customer process — and a data classification of Tier 1 (Restricted) due to the presence of PII and NPI. The inventory record is completed and approved before the deployment pipeline is authorized to promote the build to production.Example 2 — System Manager DepartureThe System Manager for a core risk calculation engine notifies HR of their resignation, with a last day in 10 days. Upon notification, the technology risk team triggers a System Manager transition workflow. A successor — a senior engineer on the same team — is designated and the inventory record is updated within 3 business days of the original System Manager’s departure, well within the 5-business-day requirement.Example 3 — Classification DisagreementDuring an annual inventory review, a data engineering team classifies their internal analytics platform as Tier 3 (Internal) for data classification, reasoning that the platform only contains aggregated metrics. Upon review, the risk team notes that the platform ingests and temporarily retains raw transaction records during ETL processing, which includes cardholder data. The classification is escalated and updated to Tier 1 (Restricted), triggering a review of the platform’s encryption posture and access control configuration.LinksThis control maps to asset inventory and lifecycle management requirements across five frameworks applicable to financial services organizations. Framework Provision Applicability Link FFIEC IT Handbook Info Security II.C.5; AIO III.B.1 US-supervised depository institutions, BHCs, and TSPs ithandbook.ffiec.gov NIST SP 800-53 Rev 5 PM-5 (System Inventory); CM-8 / CM-8(4) US federal agencies; FS best practice baseline PM-5 · CM-8 SOC 2 TSC (AICPA) CC6.1 — Inventory of Information Assets Service orgs with SOC 2 audit obligations aicpa-cima.com PCI DSS v4.0 Requirement 12.5.1 — System Component Inventory Organizations in scope for cardholder data protection pcisecuritystandards.org EU DORA Article 8 — Identification; Articles 28–30 (third-party register) All EU financial entities; effective January 17, 2025 eur-lex.europa.eu FFIECThe IT Handbook describes principles rather than prescriptive requirements. This control produces the evidence base — documented inventory, ownership, classification, and review records — that examiners typically request during examination cycles.NIST: PM-5 vs CM-8This control operates at the PM-5 level (organizational system inventory) rather than CM-8 (individual component inventory). Organizations should maintain both: this control satisfies PM-5 and anchors downstream CM-8 compliance. The System Manager attribute directly satisfies CM-8(4) — Accountability Information.SOC 2: CC6.1, not CC6.3The inventory obligation sits in CC6.1. CC6.3 addresses role-based access authorization and is a downstream consumer of the inventory this control produces, not a direct inventory requirement itself.PCI DSSOrganizations subject to PCI DSS should ensure the data classification attribute explicitly flags Tier 1 (Restricted) systems that are in scope for PCI, and should maintain network diagram traceability as a supplemental artifact.EU DORAThe criticality classification supports DORA’s identification of critical and important functions; Non-EU organizations with EU operations should assess applicability; analogous requirements exist under the UK FCA’s operational resilience rules (PS21/3 and PS24/16).
Test Evidence Retention
Test evidence retention ensures that automated test results are captured, linked to specific code changes, and preserved for audit, providing verifiable proof that software was tested before deployment.DescriptionTest evidence retention addresses the requirement to produce, on demand, machine-generated records that demonstrate testing occurred for any given code change or release. Without retained evidence, an organisation cannot prove to a regulator, auditor, or customer that its test suite operated as intended at the time a change was deployed. The mere existence of a test suite is insufficient — evidence must be tied to specific commits, cover the expected scope, and survive for the full regulatory retention period.This control is distinct from test execution (SDLC-PREV-016), which governs whether required testing was performed and any failures appropriately reviewed. Test evidence retention concerns the preservation and retrievability of the artefacts that test execution produces. An organisation may execute testing correctly but still face an evidence failure if the resulting records are not retained in a durable, tamper-evident form linked to the change they attest to.In regulated financial services environments, the inability to produce test evidence for a released change is treated by examiners as equivalent to the testing not having occurred. Coverage metrics, test run logs, pass/fail records, and the identity of the system that executed them form part of the SDLC governance trail required to demonstrate that software development risk is managed.Requirements Automated test suites MUST be executed as part of the CI/CD pipeline for every pull request targeting a protected branch and every build that produces a deployable artefact For Automated test execution results MUST be captured in a structured, machine-readable format (e.g., JUnit XML, CTRF) and stored as persistent artefacts linked to the triggering commit SHA, branch, built artifact, pipeline run identifier, and timestamp or any other references to ensure traceability back to the intented release Manual test evidence must be associated with the intented release for traceability, downstream gating and reporting. Test evidence artefacts MUST be retained for a minimum period aligned with the organisation’s regulatory audit retention policy; this period MUST NOT be less than the longest applicable regulatory retention requirement Retained artefacts MUST be immutable after capture; they MUST NOT be modifiable, deletable, or re-runnable outside an approved and auditable exception process Each deployment record MUST include a reference to the test evidence artefact that corresponds to the artefact being deployed, enabling end-to-end traceability from deployment back to the test run A defined and documented exception process MUST exist for cases where test evidence cannot be produced before deployment; exceptions MUST be approved by an appropriate authority, time-bound, and automatically tracked to closureExamples & Commentary Artefact Storage: Configure CI pipelines to publish test results and coverage reports as pipeline artefacts. Where the pipeline’s native retention is short-lived (e.g., 30 days), archive to long-term storage such as an object store with immutable object policies enabled (e.g., S3 Object Lock). Record the artefact location in the deployment record Traceability: Tag artefacts with the commit SHA or release tag so that the evidence can be addressible later by downstream gating or for reporting purposes. Immutability: Use object storage features such as write-once-read-many (WORM) policies or versioning with deletion protection to ensure artefacts cannot be altered after the pipeline writes them. Audit access logs periodically to detect any access pattern inconsistent with normal read-only retrievalLinks NIST SP 800-53r5 SA-11: Developer Testing and Evaluation NIST SP 800-53r5 AU-12: Audit Record Generation NIST SP 800-53r5 CA-2: Control Assessments NIST SSDF SP 800-218 OWASP DevSecOps Guideline
Testing Requirements
A testing policy must be defined that specifies the categories and scope of testing required before any change is released to production, proportionate to the risk profile of the change.DescriptionThis control establishes the policy layer of the organisation’s testing posture: what types of testing must be performed and when. It does not govern whether the testing was actually executed (SDLC-PREV-016), whether it was enforced mechanically (SDLC-PREV-012), or whether the results were retained (SDLC-PREV-014). Its sole concern is that the organisation has defined, documented, and maintains a testing policy that maps required testing activities to change types.The testing policy definition defines what degree of testing applies to different change types. This is particularly critical with manual testing due to the overall expense and you may wish to define when it is or is not appropriate to run which suites of testing. Without an explicit testing policy, testing decisions are left to individual judgement and vary across teams, repositories, and release cycles. This creates inconsistency, makes audit response difficult, and means the organisation cannot demonstrate that its testing expectations were defined in advance rather than rationalised after the fact. In regulated financial services environments, examiners expect a documented testing standard that exists independently of any individual release.The policy must address the full spectrum of change types — from low-risk configuration updates to security-sensitive changes — and define what testing is required for each. It should be specific enough to be enforceable and auditable, but not so prescriptive that it cannot accommodate the diversity of technologies and delivery patterns within the organisation.Requirements A testing policy MUST be defined that specifies the categories of testing required for each change classification (e.g., patch, minor feature, major release, infrastructure change, security-sensitive change) The policy MUST define a minimum testing baseline that applies to all changes regardless of classification; this baseline MUST include at minimum regression testing to confirm that existing behaviour is not broken Changes to security-sensitive components — including authentication, authorisation, session management, cryptographic operations, and data handling — SHOULD require targeted security testing in addition to functional testing Changes to critical code path that have ben identified as being partocularly sensitive to the application SHOULD require additional testing. The policy MUST define minimum code coverage thresholds per repository or service, with documented rationale for the chosen threshold appropriate to the risk profile of the component The policy MUST specify exit criteria that define what constitutes a passing test outcome for each change classification, including acceptable treatment of pre-existing known failures The testing policy MUST be reviewed at least annually, or when significant changes to the technology stack, threat landscape, or regulatory requirements occurExamples & Commentary Change Classification: Define a simple taxonomy of change types and map required testing to each. For example: a dependency patch may require automated unit and integration tests plus a DAST scan; a new customer-facing feature may additionally require functional UAT and a targeted security review; a change to the authentication flow may require penetration testing or red team exercise sign-off before release Coverage Thresholds: Define thresholds appropriate to the risk profile of each repository — a payment processing service may require 80% line coverage, while an internal tooling repository may set a lower bar. Document the rationale for the chosen threshold in the repository’s governance documentation Exit Criteria: Define release readiness criteria before testing begins, not after. Criteria should specify: no new test failures introduced by the change without documented acceptance; code coverage must not fall below the defined threshold; no new critical or high SAST or DAST findings introduced unresolved; security sign-off obtained for security-sensitive changes. Pre-existing failures that are known, tracked, and unrelated to the change may be accepted without blocking release, provided they are documented. Vague or unwritten criteria are easily gamed and do not provide meaningful assurancease. SDLC-PREV-014 (Test Evidence Retention) ensures the records of completed testing are preserved. All three are required for a complete testing assurance posture Penetration Testing: Is usually an expensive practice sometimes dedicated to a sat of experts who will testing manually or semi-automatically to see if they can breach the system overall. Doing such testing on every release may not be advisable or cost effective, especially if the release was small. This practice will need to be defined somewhere.Links NIST SP 800-53r5 SA-11: Developer Testing and Evaluation NIST SP 800-53r5 SA-15: Development Process, Standards, and Tools NIST SSDF SP 800-218 OWASP DevSecOps Guideline FFIEC IT Handbook - Information Security
Test Execution and Sign-Off
Required appropriate testing as defined by the testing policy (SDLC-PREV-015) must be executed before any change is released to production. Human review and sign-off is required only when test failures occur or when the testing policy cannot be fully satisfied.DescriptionThis control governs the execution of testing for each individual release. It bridges the gap between the testing policy (SDLC-PREV-015), which defines what testing must be performed, and the evidence trail (SDLC-PREV-014), which preserves the records of that testing. This control answers the question: for this specific change, was the required testing actually performed, and were the results acceptable?When all required testing passes and the testing policy is fully satisfied, no manual intervention is needed — the automated pipeline confirms compliance and the release may proceed. Human review and sign-off is required only in two circumstances: when test failures exist that need to be assessed and accepted, or when the testing policy cannot be fully followed and an exception is needed. This keeps the control proportionate — it does not impose manual review overhead on the majority of releases where automated testing passes cleanly, but ensures accountability when it matters.Requirements All changes released to production MUST have completed the testing categories required for their classification as defined in the testing policy (SDLC-PREV-015) before release Where all required testing passes and the testing policy is fully satisfied, the release MAY proceed without manual sign-off; the automated test results constitute sufficient evidence of compliance Where test failures exist in the results failures MUST be explicitly reviewed and either remediated or accepted by a named individual; acceptance MUST be recorded with the identity of the approver, the rationale for acceptance, and confirmation that the failure is not attributable to the change being released Where testing cannot be completed to the required standard prior to release, a documented and approved exception MUST be raised, specifying: who approved the exception, the justification, which test requirements were waived, any compensating controls applied (e.g., enhanced post-deployment monitoring), and a time-bound remediation commitmentExamples & Commentary Happy Path: When a change passes all required automated tests, meets coverage thresholds, and satisfies all gate criteria defined in the testing policy, it proceeds to release without requiring manual review. The pipeline run and its results are the evidence — no additional sign-off is needed Failed Test Acceptance: When a test failure is accepted rather than remediated, the sign-off record should include: the specific test(s) that failed, the reason the failure is considered acceptable for this release (e.g., pre-existing known issue tracked in ticket X, flaky test under investigation), and the name of the individual accepting the risk. This record forms part of the audit trail and must be preserved per SDLC-PREV-014Links NIST SP 800-53r5 SA-11: Developer Testing and Evaluation NIST SP 800-53r5 CA-2: Control Assessments NIST SSDF SP 800-218 OWASP DevSecOps Guideline FFIEC IT Handbook - Information Security
Service Dependency Control
Service Dependency Mapping provides visibility into how services and external APIs interact across systems and applications. It enables faster incident response, coordinated remediation, and reduced operational risk by maintaining an accurate, up-to-date view of runtime dependencies and their relationships at both service and application levels.This control complements Component Inventory by extending visibility from artifact-level composition to runtime service and application-level dependency relationships.DescriptionService Dependency Mapping is the practice of identifying, maintaining, and continuously updating relationships between services, applications, and their dependencies, including internal services and external APIs.While component inventory focuses on what is included within a software artifact (e.g., libraries and packages), this control focuses on how those components are used and interconnected at runtime across systems. This enables organizations to understand dependencies not only at a technical level, but also at an application and business level.The mapping provides visibility into upstream and downstream relationships, allowing teams to determine which services and applications are affected when a dependency changes, becomes unavailable, or is found to be vulnerable. It also enables identification of ownership, ensuring that responsible teams can take coordinated action within defined timelines.This control includes: Mapping service-to-service dependencies across systems Identifying which services belong to which application or business capability Tracking dependencies on external APIs, data providers, and platform services Maintaining ownership and team-level responsibility for each service and application Understanding upstream and downstream impact relationships Keeping dependency mappings aligned with production environments and deploymentsMaintaining this mapping ensures that when a failure, vulnerability, or change occurs, its impact can be quickly understood across all affected services and applications, enabling faster and more coordinated responses.Requirements Service-to-service dependencies MUST be documented and maintained for all production systems Dependencies MUST include: Internal services External APIs and third-party integrations Each service MUST be mapped to its corresponding application or business capability Ownership information MUST be maintained for each service and application to enable clear accountability during incidents Dependency mappings MUST capture upstream and downstream relationships to identify impact propagation Dependency data MUST be kept up to date with production deployments and infrastructure changes Changes to dependencies (e.g., new integrations, deprecated APIs, version upgrades) MUST be reflected in the mapping as part of the change management process Dependency mapping SHOULD be integrated with observability, incident management, or service catalog systems where possibleExamples & Commentary Vulnerability Propagation: When a critical vulnerability (e.g., Log4j) is identified in a shared library, dependency mapping enables teams to quickly identify all services using the affected library, all applications those services belong to, and the teams responsible for remediation. This allows coordinated fixes within defined timelines across the organization API Deprecation: If an external API or third-party provider becomes unavailable or deprecated, dependency mapping allows identification of all dependent services and applications, enabling faster remediation and reducing production incidents Failure Propagation: In distributed trading or real-time systems, if one service fails, dependency mapping helps identify downstream services and applications impacted, allowing proactive communication and mitigation Platform Upgrades: During platform or OS upgrades (e.g., encryption or protocol changes), dependency mapping ensures all affected services and applications are identified, preventing runtime failures due to incompatibility Incident Response: Dependency mapping reduces mean time to restore (MTTR) by enabling responders to quickly understand system relationships instead of relying on incomplete or outdated documentationLinks NIST SP 800-53r5 CM-8: System Component Inventory NIST SP 800-53r5 SI-4: System Monitoring
Dependency Curation
Dependency curation protects the organisation from open-source supply chain risk by enforcing automated, policy-driven governance on every open-source package before it enters development, build, or production use across the SDLC, much like a firewall.DescriptionOpen-source and third-party packages are fetched continuously during development and CI — from public registries (npm, PyPI, Maven Central, RubyGems, NuGet, crates.io, and others), private feeds, and cached remote repositories. Without curationcontrolling at the point of acquisition, malicious, tampered, vulnerable, or non-compliant packages can enter the estate before later controls (SBOM generation, vulnerability scanning, deployment gates) ever run.Dependency curation is the practice of controlling which package versions may be downloaded or resolved, evaluated against security and compliance policies at fetch time, and blocked or substituted before they are used in the SDLC. It operates as pre-download OSS governance: the first line of defense in the software supply chain timeline, distinct from post-build scanning or runtime detection.A curation process SHOULD cover all paths by which open-source dependencies enter the organisation, including developer workstations and IDEs, CI/CD dependency resolution, and organisation-managed binary and package repositories. Policies SHOULD be expressed in terms that security and legal teams can own (severity thresholds, license deny lists, allowlists, malicious-package blocks, immaturity or deprecation rules) while remaining enforceable automatically for developers.Curation complements Component Inventory (what is actually shipped) and Vulnerability Scanning - Dependencies (known CVEs in code already in the pipeline). Curation reduces the chance that compromised or policy-violating packages enter the graph in the first place and help reduce fix effort that increase as release process progresses; inventory and scanning remain necessary for transitive visibility, drift, and newly disclosed vulnerabilities.Requirements The organisation MUST define and maintain curation policies for open-source packages used in the SDLC, covering at minimum: known malicious or compromised packages, severity-based vulnerability thresholds, license compliance, and criteria for unapproved or restricted packages. Curation policies MUST be enforced automatically at package acquisition for all supported ecosystems and entry points used by the organisation (developer pulls, CI resolution, and organisation-managed package repositories), not solely by periodic manual review. Package repositories that proxy public or third-party registries MUST be connected to the curation control plane so that policy evaluation occurs before packages are cached or consumed downstream. Curation decisions MUST be logged and retained in accordance with the organisation’s audit and record-retention requirements.Examples & Commentary Pre-download vs post-build: Blocking a typosquatted or malicious npm package at the remote repository prevents every developer and pipeline from caching it; relying only on a weekly SCA scan on main leaves a window where the package is already in lock files and build caches. License governance: A policy that blocks copyleft or unknown-license packages at download prevents legal review debt and last-minute release blocks; pair with component inventory SBOMs for attestation of what shipped. Developer experience: Integrate curation signals into CLI and IDE workflows so developers see policy outcomes at resolution time rather than only at failed pipeline stages. Relationship to deployment gating: Curation at acquisition does not replace Deployment Gating or provenance controls; it narrows what can enter the supply chain graph that those later controls must trust.Links NIST SP 800-53r5 SR-3: Supply Chain Controls and Processes NIST SP 800-53r5 SR-11: Component Authenticity NIST SSDF SP 800-218 (PO.3) OWASP SCVS (Guidance: Open Source Policy)
Version Release Approval Gating
Version Release Approval Gating ensures that no software version is promoted to production without passing a defined approval workflow, enforced either by designated human approvers, automated policy checks, or a combination of both. It establishes a verifiable, auditable gate at the version level—distinct from per-deployment gates—that confirms the release candidate has satisfied all governance, quality, and risk requirements before any deployment is permitted.DescriptionDeployment gating (MI-12) controls whether an individual deployment job may proceed based on technical policy checks. Version Release Approval Gating operates at a higher level: it governs whether a named software version has received the organisational approval required to be released at all. A version may pass all automated deployment gates but still require explicit sign-off from a release manager, risk officer, or compliance stakeholder before it can be promoted from a candidate to an approved release.This distinction is critical in regulated financial services environments where change management frameworks require named human accountability for production releases, not merely automated technical policy satisfaction.The control supports two complementary approval mechanisms that may be used individually or in combination:Manual Approval WorkflowsNamed approvers—such as a release manager, change advisory board (CAB) member, or risk officer—explicitly authorise a release candidate before it can proceed to any production deployment. The approval is recorded against the specific version, is timestamped and attributed to an identified individual, and must be obtained before any deployment pipeline for that version is unlocked. Approval workflows may be tiered, requiring different sets of approvers depending on the risk classification of the application or the scope of the change.Automated Policy ChecksPolicy-as-code evaluations assess the release candidate against a defined set of criteria that must all pass before the version is marked approved. These checks may include confirmation that all required test suites have executed and passed, that vulnerability findings are within approved thresholds, that security scan results have been attested, that mandatory review steps in the development workflow are complete, and that the release artefact matches a signed, verified build provenance record. Automated checks produce a structured approval record that can be used as audit evidence independently of human action.In either case, the approval state is recorded at the version level in a system of record (e.g., a release management platform, ITSM tool, or policy engine), and downstream deployment pipelines are blocked from proceeding until the required approval state is confirmed.Requirements Every software version intended for production MUST be subject to a defined approval workflow before any production deployment is initiated The approval workflow MUST be enforced by the release pipeline; pipelines MUST verify the approval state of the target version before proceeding and MUST fail if approval is absent or has been revoked Approval workflows MUST specify which approver roles or automated checks are required, differentiated by application risk classification where appropriate Manual approvals MUST be attributed to a named individual, timestamped, and recorded in an auditable system of record Automated approval checks MUST produce a structured, machine-readable result that is retained as part of the release record Approval state MUST be bound to a specific, immutable version identifier (e.g., a signed artefact digest or tagged commit SHA); approval of one version MUST NOT be transferable to another A documented emergency release process MUST exist for critical production incidents requiring deployment of a non-approved version. Emergency releases MUST require real-time approval from a named authority, MUST be time-bounded, MUST be logged with documented justification, and MUST trigger a post-incident governance review Emergency release overrides MUST be reported to risk and compliance functions within a defined timeframe (e.g., next business day) Approval records, including any overrides, MUST be retained for a period consistent with applicable regulatory requirements and the organisation’s record-keeping policy The set of required approval checks and approver roles MUST be reviewed at least annually, or following any material change in the application’s risk profile, regulatory obligations, or technology stackExamples & Commentary CAB-Gated Release: For a high-criticality payment processing service, the release workflow requires approval from a release manager and a risk officer before the pipeline is permitted to deploy any build to production. The CAB review is documented in the ITSM system against the specific version tag, and the deployment pipeline queries the ITSM API to confirm approval state before executing any production deployment steps. Automated Policy-as-Code Approval: For a lower-risk internal tooling service, a policy engine evaluates the release candidate against a ruleset: all unit and integration tests passed, no critical CVEs in dependencies, SAST scan completed with no new high findings, and build provenance attestation verified. When all checks pass, the policy engine issues a signed approval record that the deployment pipeline accepts as authorisation to proceed. Tiered Approval by Change Risk: An organisation classifies changes as standard, significant, or emergency. Standard changes (low-risk, well-understood) may be approved by automated policy checks alone. Significant changes require a named release manager sign-off in addition to automated checks. Emergency changes require a senior technology officer approval, are time-limite, and trigger mandatory post-deployment review. Approval Binding to Artefact Digest: To prevent version substitution attacks or accidental promotion of a different build, approval is recorded against the SHA-256 digest of the release artefact rather than a version label alone. The pipeline verifies both that the version label matches an approved record and that the artefact digest matches the digest recorded at approval time. Revocation: If a vulnerability is discovered in a version that has already been approved but not yet fully deployed, the approval can be revoked in the system of record, and the deployment pipeline will reject further deployments of that version until a new approval is granted for a remediated build. Links