12. DevSecOps and Continuous Security

Introduction and Context

Software security was once treated largely as a specialist activity performed near the end of the development life cycle. Security teams reviewed applications before release, penetration testers searched for exploitable weaknesses, and operations teams focused on availability and performance. This arrangement was poorly aligned with modern software delivery. Applications are now assembled from open-source dependencies, cloud services, containers, infrastructure-as-code, managed platforms, and rapidly changing interfaces. A vulnerability introduced in source code may be replicated across build artifacts, cloud environments, and production systems within minutes.

DevSecOps responds to this reality by integrating security into the social, technical, and managerial practices of DevOps. It does not mean simply adding more security tools to a CI/CD pipeline. It means establishing shared ownership of security, automating repeatable controls, making risk visible to delivery teams, and designing workflows in which secure behaviour is the easiest practical behaviour. Continuous security extends this idea beyond a single release. Security controls operate continuously across planning, coding, version control, building, testing, provisioning, deployment, operation, monitoring, and remediation.

The strategic importance of DevSecOps lies in its treatment of security as a property of the delivery system rather than an inspection performed on the final product. This approach can improve speed and reliability, but only when controls are proportionate, results are actionable, and governance distinguishes genuinely dangerous findings from low-value noise. The central challenge is therefore not automation alone. It is the design of a socio-technical system that balances delivery velocity, resilience, compliance, confidentiality, integrity, and business risk.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the relationship between DevOps, DevSecOps, and continuous security.

2. Identify security controls appropriate to source control, build, CI/CD, infrastructure-as-code, and deployment.

3. Describe policy as code, secrets detection, software composition analysis, static and dynamic testing, and security gates.

4. Design a risk-based secure delivery pipeline with suitable feedback and telemetry.

5. Analyse the organisational, technical, ethical, and governance implications of DevSecOps.

6. Evaluate common implementation failures and recommend improvements.

7. Apply DevSecOps principles to a realistic software delivery scenario.

From DevOps to DevSecOps

DevOps integrates development and operations through collaboration, automation, shared metrics, and continuous delivery. Its objective is not merely to release more frequently; it is to create a reliable flow from a business idea to a monitored and supportable service. DevSecOps adds security as a first-class quality attribute within that flow.

A useful distinction is between security added to DevOps and security integrated into DevOps. In the first case, a security team may attach a scanning step to an existing pipeline. In the second, security requirements are defined during planning, developer tools provide immediate feedback, identity and access are controlled in repositories, infrastructure is validated before provisioning, and production telemetry informs future engineering decisions. Security becomes part of normal work rather than an exceptional interruption.

DevSecOps is often described through three mutually reinforcing dimensions:

• People and culture: developers, operations personnel, security practitioners, product owners, and risk managers share responsibility for outcomes.
• Process and governance: security requirements, risk acceptance, change control, incident response, and compliance evidence are integrated into delivery processes.
• Technology and automation: tools continuously analyse code, dependencies, configurations, identities, artifacts, deployments, and runtime behaviour.

No dimension is sufficient by itself. Automated scanning without skilled interpretation produces alert fatigue. A security-conscious culture without enforceable controls cannot reliably prevent mistakes. Governance without usable tooling may drive teams to bypass approved processes.

Security Across the Software Delivery Flow

Planning and design

Security begins before code exists. Product teams should identify assets, trust boundaries, users, abuse cases, legal obligations, and consequences of compromise. Lightweight threat modelling can expose risks such as unauthorised privilege escalation, insecure tenant separation, exposed administrative interfaces, or unsafe handling of personal data. Security requirements should be expressed in verifiable terms—for example, “administrative actions require phishing-resistant multi-factor authentication” is more useful than “the system must be secure.”

Architecture decisions should record assumptions about identity, encryption, network exposure, data retention, third-party services, recovery, and logging. Design review need not become a bureaucratic gate for every change. Its depth should correspond to factors such as data sensitivity, internet exposure, privilege, system criticality, and novelty of technology.

Version control and collaboration

The source repository is a security boundary. Repositories should require authenticated access, least privilege, protected branches, peer review, and auditable changes. Direct pushes to protected branches should normally be prohibited, and high-risk changes—such as authentication logic, cryptographic configuration, or deployment permissions—may require reviewers with appropriate expertise.

Commit signing or equivalent provenance mechanisms can strengthen confidence in authorship, although signing does not prove that the code itself is safe. Repository settings should prevent accidental exposure of private repositories, restrict workflow modifications, and protect build credentials. Pull requests provide a useful point for automated checks, but a passing check must not be interpreted as proof of security. It indicates only that specified tests and policies were satisfied.

Secrets must never be treated as ordinary source data. API keys, passwords, private certificates, tokens, and cloud credentials should be stored in an approved secrets manager and injected only at the point of use. Secrets-detection tools can scan commits, branches, pull requests, and historical repositories. When a secret is discovered, deleting the line is insufficient: the credential must be revoked or rotated, affected systems assessed, and repository history considered.

Build integrity and artifact security

A build system transforms source into artifacts such as packages, container images, binaries, and deployment manifests. It is therefore a high-value target. Build workers should be isolated, regularly patched, minimally privileged, and prevented from accessing unrelated production credentials. Build definitions should be versioned and reviewed like application code.

Dependency resolution should be controlled through trusted registries, lock files, approved versions, and reproducible or at least traceable builds. Software bills of materials (SBOMs) describe components included in an artifact and support vulnerability response, licensing review, and asset inventory. An SBOM is an inventory, not a security guarantee; it must be connected to accurate vulnerability intelligence and prioritisation.

Artifact repositories should enforce access controls, retention rules, immutability where appropriate, and provenance records. Artifact signing allows consumers to verify that an artifact came from an authorised build process and was not altered after creation. Provenance information can record source revision, builder identity, dependencies, and build parameters. These controls support a chain of trust from source to deployment.

Security testing in CI/CD

Different automated tests answer different questions:

• Static application security testing (SAST) analyses source, bytecode, or intermediate representations for patterns associated with vulnerabilities.
• Software composition analysis (SCA) identifies open-source components, versions, known vulnerabilities, and sometimes licence obligations.
• Secret scanning searches for credentials and other sensitive material.
• Infrastructure-as-code scanning identifies insecure cloud, network, identity, and platform configurations before deployment.
• Dynamic application security testing (DAST) examines a running application from an external perspective.
• Interactive application security testing (IAST) combines runtime observation with application instrumentation.
• Container and artifact scanning evaluates packages, operating-system layers, configuration, and image metadata.
• Fuzzing supplies unexpected or malformed inputs to discover robustness and security defects.

These methods have different coverage and error characteristics. SAST may find a dangerous data-flow path but also produce false positives. DAST can demonstrate externally observable behaviour but may miss unexercised paths. SCA may identify a vulnerable library even when the vulnerable function is not reachable. Consequently, mature pipelines combine tools rather than treating any one scanner as authoritative.

Infrastructure-as-code and policy as code

Infrastructure-as-code (IaC) defines infrastructure in declarative or programmatic form. It improves repeatability and reviewability, but insecure templates can reproduce insecure environments at scale. IaC controls should examine network exposure, storage permissions, encryption, identity privileges, logging, backup settings, and approved regions or services. Plans should be reviewed before application, and state files must be protected because they may contain sensitive values.

Policy as code expresses organisational or security rules in machine-evaluable form. Examples include “public storage is prohibited,” “production workloads must use approved images,” “containers may not run as root,” or “a deployment to a regulated environment requires two approvals.” Policy can be evaluated during pull requests, build execution, admission to a cluster, or cloud configuration monitoring.

Policy as code improves consistency and auditability, but policies must be carefully designed. An overly broad rule can block legitimate work; an incomplete rule can create false confidence. Policies should specify scope, exceptions, ownership, severity, and an expiry mechanism for temporary waivers. Exceptions should be visible and risk-accepted by an accountable authority rather than silently disabling the control.

Deployment and hardened environments

Deployment controls should ensure that only approved, tested, and traceable artifacts reach protected environments. Common practices include environment separation, short-lived credentials, deployment identities with least privilege, manual or multi-party approval for high-risk production changes, and progressive delivery. Blue-green deployment, canary release, and feature flags can limit blast radius and permit rapid rollback.

Runtime environments should be hardened through minimal images, removal of unnecessary packages, restricted privileges, network segmentation, secure defaults, patch management, workload identity, and controlled administrative access. Containers are not security boundaries by themselves; the host, orchestrator, registry, admission controls, and runtime configuration also require protection. Serverless and managed services reduce some operational responsibilities but do not eliminate identity, data, application, or configuration risks.

Security gates should be based on risk rather than arbitrary tool output. A critical secret exposure, exploitable authentication flaw, or deployment of an unapproved artifact may justify an immediate block. A low-confidence informational finding may be recorded for later remediation. Gate design should consider severity, exploitability, asset criticality, reachability, compensating controls, and whether the finding is new or previously accepted.

A Risk-Based Continuous Security Model

A practical model for continuous security has five connected activities: discover, prevent, detect, respond, and learn.

Discover means maintaining visibility of source repositories, dependencies, artifacts, cloud resources, identities, data, and deployed services. Asset inventory and SBOMs are essential because an organisation cannot protect what it cannot identify.

Prevent includes secure design, least privilege, hardened templates, secrets management, code review, secure defaults, and automated policy enforcement. Prevention is generally less expensive than emergency remediation, but prevention controls should not be so restrictive that teams circumvent them.

Detect uses scanners, audit logs, runtime telemetry, threat detection, dependency alerts, configuration monitoring, and user reports. Detection should be mapped to response ownership and service-level expectations.

Respond includes triage, containment, credential rotation, patching, rollback, incident investigation, communication, and recovery. Pipeline integrations can create tickets or trigger workflows, but human judgement remains necessary for ambiguous or high-impact events.

Learn converts incidents, near misses, recurring findings, and delivery metrics into improved controls, training, architecture, and policies. Without learning, automation merely repeats the same failure at greater speed.

This model is compatible with the principle of continuous improvement. Controls should be evaluated not only by the number of findings they generate but by whether they reduce meaningful exposure without damaging delivery reliability.

Feedback, Telemetry, and Security Metrics

DevSecOps requires feedback at several speeds. Developers need rapid, local feedback for formatting, secrets, and simple static checks. Pull requests can provide richer analysis within minutes. Nightly or scheduled processes can perform deeper scans. Runtime monitoring supplies operational feedback after deployment.

Useful metrics include mean time to remediate vulnerabilities, age of critical findings, percentage of assets with current SBOMs, percentage of deployments using approved artifacts, secret-exposure recurrence, policy-exception age, and the proportion of production changes covered by traceable tests. Metrics should be interpreted carefully. A reduction in findings may represent improved security—or simply disabled scanning. Similarly, a high patching rate may conceal repeated introduction of the same defect.

A balanced measurement system combines leading indicators, such as threat-model coverage and secure-training completion, with lagging indicators, such as incidents and unauthorised changes. Metrics should support learning rather than punish teams for reporting problems. If teams are rewarded only for low defect counts, they may suppress reporting or classify findings strategically.

Organisational and Managerial Considerations

DevSecOps changes responsibilities. Security specialists increasingly act as enablers, platform designers, reviewers, and mentors rather than the sole owners of application security. Developers are responsible for addressing security defects in the code they create, while platform teams provide secure deployment paths and reusable controls. Product and executive leaders decide how much risk is acceptable in relation to business objectives.

A useful operating model combines central standards with distributed execution. A central security or platform group can maintain approved pipeline components, policy libraries, reference architectures, detection rules, and specialist support. Product teams retain responsibility for their services and risks. This arrangement avoids both extremes: uncontrolled autonomy and a central team that becomes a delivery bottleneck.

Security champions embedded in development teams can improve communication and local capability. Their role should be supported with time, training, and access to experts; appointing a volunteer without organisational support is unlikely to produce sustained results. Training should be role-specific. Developers may need secure coding and dependency-management skills, while operations teams require knowledge of identity, cloud configuration, logging, and incident response.

An Illustrative Case Study: Securing a Financial Services Delivery Pipeline

Background

The fictional organisation Northbridge Payments operates an online payment platform composed of web services, mobile APIs, containerised workloads, and managed cloud databases. It releases several times each day. Security reviews are performed before major releases, but minor releases often bypass formal review. The organisation has experienced two incidents: a cloud storage bucket was unintentionally exposed, and an API token was committed to a private repository and later misused.

Situation and problem

Senior management wants faster delivery but has also received audit findings concerning excessive cloud permissions, incomplete vulnerability records, and weak evidence linking production artifacts to source code. The security team proposes blocking every pipeline whenever any scanner reports a finding. Engineering leaders reject this proposal because existing scans produce many false positives and would interrupt ordinary development.

Analysis

The problem is not simply a shortage of scanning. Northbridge lacks a complete asset inventory, clear ownership, protected build processes, and a risk-based decision model. A universal blocking rule would create operational friction without distinguishing a critical exposed credential from a low-confidence code warning. The organisation also needs evidence that a deployed artifact was built from reviewed source and that infrastructure complied with approved policy.

Approach and strategy

Northbridge first classifies services according to data sensitivity, internet exposure, privilege, and business criticality. It then establishes the following controls:

1. Protected branches and mandatory peer review are enabled for all repositories; changes to authentication and deployment workflows require specialist review.

2. A managed secrets service replaces credentials stored in repositories and CI variables. Secret scanning runs locally, during pull requests, and against repository history. Exposed credentials are automatically disabled where technically possible.

3. Build runners are isolated, ephemeral, and granted narrowly scoped identities. Artifacts are signed, stored in an immutable repository, and accompanied by SBOMs and provenance data.

4. IaC templates are checked for public storage, unrestricted network access, excessive privileges, missing encryption, and absent logging. Exceptions require an owner, justification, compensating control, and expiry date.

5. SAST, SCA, container scanning, and DAST are combined. A release is blocked for confirmed critical vulnerabilities in reachable production code, active credentials, unapproved artifacts, or mandatory policy violations. Medium-risk findings create tracked work with deadlines.

6. Production deployment uses canary release and automatic rollback based on service health and security telemetry. Runtime monitoring detects unusual identity use, unexpected outbound traffic, and changes to protected resources.

7. A dashboard reports remediation age, policy exceptions, artifact provenance, exposed-secret recurrence, and deployment outcomes. Teams review trends monthly rather than competing for the lowest raw finding count.

Outcome

The new system does not eliminate all vulnerabilities, but it reduces the probability that common errors reach production and makes the remaining risk more visible. Developers receive faster feedback for issues they can fix immediately, while security specialists focus on high-impact design and investigation. Audit evidence is generated from normal delivery activity rather than assembled manually at release time.

Learning points

The case demonstrates that DevSecOps is an operating-model change, not a scanner installation project. Risk-based gates are more sustainable than universal blocking. Secrets require revocation and lifecycle management, not merely detection. Provenance and SBOMs improve response capability but must be connected to ownership and vulnerability intelligence. Finally, security metrics should encourage truthful reporting and remediation rather than concealment.

Challenges, Limitations, and Common Mistakes

A frequent mistake is tool accumulation. Organisations purchase multiple scanners without integrating ownership, deduplication, severity calibration, or remediation workflows. The result is alert fatigue. A smaller set of well-configured tools with clear response paths is usually more valuable than a large disconnected portfolio.

Another problem is treating severity labels as objective truth. Scanner severity may not reflect exploitability, reachability, data sensitivity, or compensating controls. Risk-based triage requires context and periodic reassessment. Conversely, contextual prioritisation must not become a justification for ignoring systemic weaknesses.

Pipelines can also become a single point of failure. If every deployment depends on one unavailable service or an incorrectly configured policy engine, security automation can damage availability. Critical controls should have tested failure modes, clear emergency procedures, and secure break-glass access. Emergency access must be logged and reviewed rather than becoming a permanent bypass.

Insecure pipeline permissions are particularly dangerous. A build job that can modify production infrastructure or read all organisational secrets creates a concentration of privilege. Workflows should use separate identities, short-lived tokens, environment boundaries, and explicit permissions. Pull-request code from untrusted contributors should not execute with privileged credentials.

Other common failures include scanning only after deployment, failing to scan historical repositories, trusting vulnerable base images, ignoring IaC state files, allowing permanent policy exceptions, and confusing compliance evidence with actual security. Automation cannot compensate for unclear architecture, poor ownership, or inadequate incident response.

Ethical, Governance, and Regulatory Considerations

Continuous security involves extensive collection of data: source code, developer identities, build logs, dependency information, cloud activity, and runtime events. Organisations should collect what is necessary, restrict access, protect logs, and define retention periods. Developer monitoring should serve security and reliability rather than become disproportionate surveillance.

Governance should define who may approve exceptions, accept residual risk, alter security policies, and access sensitive telemetry. Segregation of duties may be required for highly regulated systems, but it should be implemented intelligently so that independent oversight does not create unreviewed manual workarounds.

Regulatory obligations differ by sector and jurisdiction, but recurring expectations include access control, change traceability, vulnerability management, incident response, evidence preservation, and protection of sensitive data. DevSecOps can strengthen compliance by generating reliable evidence automatically; it cannot replace interpretation of applicable laws, contracts, standards, or professional duties.

Ethically, teams must consider the consequences of both insecure delivery and excessive restriction. A vulnerable service may harm customers, while an inflexible control may delay critical safety or public-service functionality. Decisions should be transparent, proportionate, and based on defensible risk reasoning.

Emerging Developments

Software supply-chain security is receiving increasing attention through provenance, artifact signing, SBOMs, trusted build systems, and verification at deployment. These practices address the possibility that attackers compromise dependencies, registries, build tools, or release infrastructure rather than the application source itself.

Identity-centred security is also becoming more important as workloads move across cloud and hybrid environments. Short-lived workload identities, federated access, continuous authentication, and policy-based authorisation reduce dependence on long-lived credentials.

Artificial intelligence is being used to prioritise findings, summarise code changes, generate tests, detect anomalous activity, and assist with remediation. Its output must be treated as advisory unless independently verified. AI-generated code can reproduce insecure patterns, introduce licensing uncertainty, leak sensitive prompts or context, and create false confidence. Secure development policies should therefore address approved tools, data handling, review responsibility, and testing of generated code.

Continuous authorisation and runtime policy enforcement are developing alongside continuous delivery. Instead of trusting an artifact solely because it passed a build, deployment systems can evaluate its provenance, vulnerability state, identity, environment, and current policy at admission time. This is powerful but increases the need for dependable policy engineering and well-designed emergency procedures.

Best-Practice Guidance

A mature DevSecOps programme generally follows these principles:

• Establish security ownership for every service, repository, artifact, and production environment.
• Start with high-impact risks and a small number of reliable controls.
• Protect repositories, build systems, registries, deployment identities, and secrets as critical infrastructure.
• Make secure paths easier through reusable pipeline templates and approved platform capabilities.
• Use layered testing and correlate results rather than relying on one scanner.
• Apply risk-based, explainable security gates with controlled exceptions.
• Generate SBOMs and provenance records for important artifacts.
• Treat infrastructure and policy definitions as reviewable, testable code.
• Instrument production for detection, response, and feedback.
• Measure remediation quality and recurrence, not merely scan volume.
• Test rollback, credential rotation, incident response, and emergency access.
• Review controls regularly as architectures, threats, regulations, and delivery practices change.

Chapter Summary

DevSecOps embeds security in the complete software delivery system, from planning and source control to build, deployment, runtime monitoring, and learning. Its success depends on the interaction of culture, governance, and automation. Important controls include protected repositories, secrets management, secure build runners, dependency and artifact analysis, SBOMs, provenance, IaC scanning, policy as code, hardened environments, and risk-based security gates.

Continuous security is best understood as a cycle of discovering assets, preventing weaknesses, detecting harmful conditions, responding effectively, and learning from evidence. Metrics and telemetry should support improvement rather than encourage concealment. Organisations must balance speed, reliability, security, compliance, and human judgement. The strategic lesson is that secure delivery is not achieved by adding a final security checkpoint; it is achieved by making security a continuous and accountable property of the delivery architecture.

Key Terms

DevSecOps: An approach that integrates security responsibilities, practices, and automation throughout DevOps delivery.

Continuous security: Ongoing security assessment, enforcement, monitoring, response, and improvement across the software life cycle.

CI/CD: Continuous integration and continuous delivery or deployment practices that automate software build, test, and release activities.

Security gate: A condition in a workflow that permits, delays, or blocks progression according to defined security criteria.

Policy as code: Machine-readable rules that automatically evaluate and enforce organisational or security requirements.

Infrastructure-as-code: Definitions of computing, network, identity, and platform resources in versioned, executable or declarative form.

SAST: Static application security testing that analyses code or program representations without executing the application.

DAST: Dynamic application security testing that examines a running application from an external perspective.

SCA: Software composition analysis that identifies third-party components, vulnerabilities, and sometimes licence obligations.

SBOM: A software bill of materials listing components and dependencies contained in an artifact.

Artifact provenance: Information describing how, where, and from which source an artifact was produced.

Secrets management: Controlled creation, storage, use, rotation, and revocation of credentials and other sensitive values.

Threat modelling: A structured process for identifying assets, threats, trust boundaries, attack paths, and mitigations.

Software supply chain: The people, processes, tools, dependencies, infrastructure, and artifacts involved in producing and delivering software.

Progressive delivery: Releasing changes gradually through techniques such as canary or blue-green deployment.

Security telemetry: Logs, events, metrics, traces, and signals used to understand security-relevant behaviour.

Risk acceptance: A formal decision to tolerate a specified residual risk under defined authority and conditions.

Security champion: A member of a delivery team who promotes security practices and connects the team with security specialists.

Review Questions

Short Answer Questions

1. Distinguish between adding security to DevOps and integrating security into DevOps.

2. Why should secrets be revoked or rotated after detection in a repository?

3. What information does an SBOM provide, and what does it not guarantee?

4. Define policy as code and give one example of a policy it may enforce.

5. Why is a risk-based security gate preferable to blocking every scanner finding?

Long Answer Questions

1. Explain how security controls can be distributed across planning, version control, build, deployment, and runtime operation.

2. Compare SAST, SCA, DAST, IaC scanning, and container scanning, including their respective strengths and limitations.

3. Discuss how a central security or platform team can support distributed ownership without becoming a delivery bottleneck.

4. Analyse the role of telemetry and metrics in continuous security, including the danger of poorly designed measures.

5. Explain how software supply-chain security practices establish trust from source code to production deployment.

Analytical / Application Questions

1. A pipeline reports 400 findings, but only three involve internet-facing services and reachable critical vulnerabilities. Design a triage and gating approach and justify your priorities.

2. A developer submits a pull request from an external fork. The workflow needs to run tests, but the repository also contains cloud credentials for deployment. What controls should be applied and why?

3. An organisation has frequent production releases, permanent policy exceptions, and no reliable artifact inventory. Propose a staged DevSecOps improvement plan that balances delivery speed with risk reduction.

22. Multiple Choice Questions with Answers

Question 1

Which practice most directly establishes a traceable chain of trust from reviewed source code to a deployed artifact?

A. Running a formatting check on every commit

B. Signing artifacts and recording build provenance

C. Increasing the number of pull-request reviewers

D. Scanning only the production network

Correct Answer: B. Signing artifacts and recording build provenance

Question 2

A secret is discovered in a private repository. What is the most appropriate immediate response?

A. Delete the line and continue the build

B. Rename the repository and retain the credential

C. Revoke or rotate the credential and investigate its use

D. Suppress the scanner finding permanently

Correct Answer: C. Revoke or rotate the credential and investigate its use

Question 3

Which statement best describes policy as code?

A. A document explaining security expectations to developers

B. Machine-evaluable rules that enforce defined requirements

C. A manual approval performed before every deployment

D. A source-code encryption technique

Correct Answer: B. Machine-evaluable rules that enforce defined requirements

Question 4

Why should a critical vulnerability in reachable production code generally receive different treatment from a low-confidence informational finding?

A. All scanner findings have identical risk

B. Risk depends on context such as exploitability, reachability, and asset criticality

C. Informational findings are always false positives

D. Critical findings require no human review

Correct Answer: B. Risk depends on context such as exploitability, reachability, and asset criticality

Question 5

Which control most directly reduces the risk that untrusted pull-request code can access production credentials?

A. Allowing all workflows to use a shared administrator token

B. Using isolated execution and narrowly scoped, short-lived identities

C. Disabling code review for external contributors

D. Storing credentials in the repository history

Correct Answer: B. Using isolated execution and narrowly scoped, short-lived identities

Question 6

What is the principal purpose of an SBOM?

A. To guarantee that software contains no vulnerabilities

B. To list software components and dependencies in an artifact

C. To replace runtime monitoring

D. To encrypt application source code

Correct Answer: B. To list software components and dependencies in an artifact

Question 7

Which deployment strategy most directly limits blast radius while providing an opportunity to observe security and operational behaviour?

A. Deploying simultaneously to every production instance

B. Canary deployment

C. Removing rollback capability

D. Using a single permanent production credential

Correct Answer: B. Canary deployment

Question 8

An organisation measures success only by the number of vulnerabilities reported by scanners. What is the primary weakness of this metric?

A. It necessarily measures business revenue

B. Teams may suppress findings or disable scanning rather than improve security

C. It prevents all false negatives

D. It measures remediation time accurately

Correct Answer: B. Teams may suppress findings or disable scanning rather than improve security

Question 9

Which activity belongs to the ‘learn’ stage of a continuous security model?

A. Creating an asset inventory

B. Blocking an unapproved artifact

C. Using incident and near-miss evidence to improve controls

D. Issuing a temporary production credential

Correct Answer: C. Using incident and near-miss evidence to improve controls

Question 10

A policy exception has no owner or expiry date. What is the main governance risk?

A. The exception will automatically improve security

B. Temporary residual risk may become invisible and permanent

C. The application will necessarily stop functioning

D. The SBOM will become unreadable

Correct Answer: B. Temporary residual risk may become invisible and permanent