Vulnerability Management and DevSecOps

Introduction

Cloud services change rapidly. Virtual machines are replaced by images, applications are deployed through automated pipelines, and infrastructure is created from code rather than configured manually. These characteristics improve speed and scalability, but they also increase the number of assets, dependencies, identities, configurations and interfaces that must be protected. A vulnerability that remains undiscovered in a cloud workload may be exploited before a security team is aware that the workload exists.

Vulnerability management is the continuous practice of identifying, assessing, treating and verifying weaknesses in technology assets. DevSecOps extends this practice by embedding security activities into development and operations rather than treating security as a final approval gate. Together, they support a risk-based approach to cloud security and data protection.

A useful lifecycle is:

Discover → assess → prioritize → remediate → validate → monitor → improve

The lifecycle is continuous because assets, software versions, threats and business priorities change continuously.

Learning Objectives

By the end of this chapter, learners should be able to:

1. Explain the purpose and lifecycle of vulnerability management.
2. Conduct basic discovery and classification of cloud assets.
3. Distinguish vulnerability scanning from risk prioritization.
4. Select appropriate remediation and validation methods.
5. Explain how security is integrated into CI/CD pipelines.
6. Describe infrastructure as code, dependency management and SBOMs.
7. Identify important software supply-chain controls.
8. Apply these ideas to a practical cloud deployment scenario.

1. Foundations of Vulnerability Management

A vulnerability is a weakness that can be exploited to compromise confidentiality, integrity or availability. Vulnerabilities may exist in operating systems, libraries, container images, cloud configurations, application logic, identities or deployment processes. A threat is a potential cause of harm, such as a criminal group, malicious insider or automated worm. Risk is the possibility that a threat will exploit a vulnerability and produce an adverse impact.

Vulnerability management is broader than vulnerability scanning. Scanning is an assessment activity; management includes governance, ownership, prioritization, remediation, exceptions and verification. A mature program answers five questions:

• What assets exist?
• What weaknesses affect them?
• Which weaknesses matter most to this organization?
• Who will correct them, and by when?
• How will correction be demonstrated?

Asset discovery as the foundation

An organization cannot protect assets that it does not know about. Cloud discovery should identify, where applicable:

• accounts, subscriptions, projects and regions;
• virtual machines, containers, serverless functions and managed databases;
• storage buckets, queues, APIs and network endpoints;
• source repositories, build systems and artifact registries;
• identities, service accounts, keys and privileged roles;
• data stores and the types of data they contain.

Discovery combines cloud-provider inventories, configuration-management databases, network observations, endpoint agents, repository searches and tagging standards. Automated discovery should be reconciled with ownership information. An asset record is more useful when it includes an owner, environment, business service, data classification, internet exposure and lifecycle status.

A practical classification is:

Discovery must also address ephemeral assets. A container or temporary build runner may exist for only minutes, so periodic manual inventories are inadequate. Cloud APIs, event-driven registration and deployment metadata are more suitable for short-lived resources.

2. Scanning and Assessment

Different assessment methods reveal different classes of weakness.

No scanner is complete. A false positive is a reported issue that is not actually present or exploitable; a false negative is a missed issue. Results therefore require human review, asset context and, for important findings, controlled verification. Scanning must be authorized and carefully scheduled because aggressive testing can disrupt services or trigger defensive controls.

A vulnerability identifier such as a CVE identifies a publicly catalogued software weakness, but the identifier alone does not determine organizational risk. The vulnerable component may not be present in the deployed image, may be unreachable, or may be protected by compensating controls. Conversely, an uncatalogued cloud misconfiguration may be highly dangerous even without a CVE.

3. Prioritization and Risk-Based Treatment

Treating every finding identically is impractical. Prioritization should combine technical severity with business context. Relevant factors include:

• exploitability and evidence of exploitation;
• internet or untrusted-network exposure;
• asset criticality and data sensitivity;
• privileges available after exploitation;
• availability of a safe fix or mitigation;
• age of the finding and recurrence history;
• contractual, legal or regulatory obligations.

A simple qualitative model is often more useful at certificate level than an apparently precise numerical score. For example, an internet-facing production identity service with a known exploited authentication flaw should receive urgent attention even if another internal development server has a higher scanner score.

Organizations commonly define service-level objectives (SLOs), such as correcting critical findings within a specified number of days. SLOs should be risk-based and should distinguish emergency action from routine remediation. They are not substitutes for judgment.

A finding record should contain the asset, evidence, affected version or setting, severity, business impact, owner, due date, remediation plan, exception status and validation evidence. Risk acceptance must be explicit, time-limited and approved by an accountable authority. It should state why the risk is accepted, what compensating controls exist and when the decision will be reviewed.

4. Remediation, Mitigation and Validation

Treatment options include:

1. Remediation: install a patch, upgrade a library, correct code or change a configuration.
2. Mitigation: reduce exposure through network controls, access restrictions, monitoring or temporary disabling.
3. Avoidance: remove the vulnerable feature or retire the asset.
4. Transfer: shift part of the consequence through contractual or insurance arrangements; this does not remove the technical weakness.
5. Acceptance: knowingly retain the risk under documented authority.

Patching is a process, not merely a command. It requires inventory accuracy, testing, backups or rollback capability, change approval appropriate to the risk, deployment, monitoring and verification. Immutable images and redeployment are often safer than manually modifying long-lived servers because they produce repeatable states.

Validation must test the original finding. A successful patch-management job is not sufficient evidence if the vulnerable package remains in the deployed image. Useful validation includes rescanning, checking package versions, testing configuration state, confirming that an exposed endpoint is no longer reachable and reviewing deployment evidence. Validation should occur in the actual production context when safe, or in a representative environment followed by controlled production confirmation.

A useful distinction is between remediation validation and risk validation. Remediation validation asks, “Was the change applied?” Risk validation asks, “Is the weakness no longer exploitable or sufficiently controlled?” The second question is more important.

5. DevSecOps and the Secure Delivery Lifecycle

DevSecOps integrates security with development, operations and business delivery. It does not mean that developers become the only security specialists. Rather, responsibility is shared, security expertise is made available early, and controls are automated where reliable.

A secure delivery lifecycle may include:

• Plan: define security requirements, data classifications and abuse cases.
• Code: use secure coding practices, peer review and secret scanning.
• Build: perform static analysis, dependency checks and reproducible builds.
• Test: conduct unit, integration, dynamic and security tests.
• Package: sign and record artifacts and generate an SBOM.
• Deploy: apply policy checks, approvals and least-privilege identities.
• Operate: monitor behavior, vulnerabilities and configuration drift.
• Respond: investigate incidents, revoke compromised credentials and rebuild affected artifacts.

Security controls should be placed as close as possible to the point where defects are introduced. A hard-coded credential detected before commit is cheaper and safer to correct than a leaked credential discovered after deployment. Nevertheless, early controls do not eliminate the need for runtime monitoring and independent assessment.

CI/CD security gates

A pipeline can contain gates for prohibited secrets, unacceptable license or dependency risk, vulnerable base images, unsafe infrastructure changes and missing approvals. Gates should be designed carefully. If every warning blocks every deployment, teams may disable the controls or create workarounds. A practical design distinguishes blocking conditions from warnings and provides an exception workflow with expiration and ownership.

Pipeline identities must be treated as privileged production identities. They should use short-lived credentials, narrowly scoped permissions, protected branches, isolated runners and auditable approvals. Build logs must not disclose secrets, and artifacts should be stored in controlled registries.

6. Infrastructure as Code

Infrastructure as code (IaC) represents networks, identities, compute, storage and policies in declarative or procedural files. IaC improves repeatability, reviewability and recovery, but insecure code can reproduce insecure infrastructure at scale.

Important IaC controls include:

• peer review and protected repositories;
• static policy analysis before deployment;
• secure modules with documented defaults;
• state-file protection, encryption and access control;
• separation of planning from approval and application;
• drift detection between declared and deployed state;
• prevention of public exposure and excessive privileges;
• version pinning and integrity verification for modules.

A plan is not proof of safety. A change that appears harmless in isolation may expose a database when combined with existing network rules. Policy-as-code can enforce organization-wide requirements, while human review considers business context and unusual changes.

7. Dependency Management and SBOMs

Modern applications depend on direct and transitive components. A direct dependency is selected by the application team; a transitive dependency is introduced by another dependency. Vulnerability management must identify both. Version ranges that silently select new releases can create unexpected behavior, while completely frozen versions can leave known weaknesses uncorrected.

Good practice includes maintaining dependency manifests and lockfiles, reviewing upgrade provenance, using trusted registries, removing unused components, monitoring advisories and testing upgrades. Dependency confusion attacks exploit package-name resolution by causing a build to retrieve a malicious package from an unintended source. Explicit private-registry configuration and namespace controls reduce this risk.

A software bill of materials (SBOM) is an inventory of components in a software artifact. It may include package names, versions, suppliers, hashes, licenses and relationships between components. SBOMs help answer “Where is this vulnerable component deployed?” but they do not prove that an artifact is safe. An SBOM can be incomplete, stale or inaccurate, and it may not describe configuration or runtime behavior.

SBOMs should be generated from trusted build stages, associated with immutable artifact identifiers, signed or integrity-protected, stored with access controls and refreshed when artifacts change. When an advisory is issued, organizations can query SBOM inventories to identify affected products and prioritize response.

8. Software Supply-Chain Security

The software supply chain includes source code, developers, dependencies, build tools, runners, artifact repositories and deployment systems. Controls should address provenance and integrity throughout this chain.

Key controls include:

• strong identity and multifactor authentication for repositories;
• least privilege for developers, bots and build systems;
• branch protection and mandatory review for sensitive changes;
• isolated and ephemeral build environments;
• dependency allowlists and trusted registries;
• artifact signing and signature verification;
• provenance statements describing how an artifact was built;
• tamper-evident logs and protected release records;
• rapid revocation and rebuild procedures.

Artifact signing establishes that an artifact corresponds to a signing identity and has not changed after signing. It does not establish that the source code was secure or that the signer was authorized. Verification must therefore include trusted identity, provenance, policy and vulnerability evidence.

9. Applied Case: Illustrative Online Learning Platform

Background

An illustrative organization operates a cloud-based learning platform. Its web application runs in containers, data is stored in a managed database, and infrastructure is deployed through IaC. The development team releases several times per week.

Problem

A routine review identifies three findings: an internet-facing container uses an outdated framework, a storage bucket is publicly readable, and a CI pipeline uses a long-lived cloud access key. The scanner rates the framework issue as high, but the other findings as medium.

Analysis

Context changes the priority. The public bucket may expose student records and therefore has high confidentiality impact. The long-lived key creates a supply-chain and account-compromise risk because anyone obtaining the key could act through the pipeline. The framework issue may permit code execution, but its practical risk depends on exploitability, application exposure and whether the vulnerable code path is reachable.

The team confirms ownership and evidence, preserves relevant logs, and checks whether the bucket has been accessed by unauthorized principals. It also inventories artifacts to determine where the framework is deployed.

Approach and solution

The bucket policy is changed to private access, access is granted through an authenticated application role, and historical access logs are reviewed. The long-lived key is revoked and replaced with short-lived, federated pipeline credentials. The container base image and framework are upgraded, rebuilt and scanned. The pipeline is updated to generate an SBOM, sign the image and block deployment when critical policy conditions are met. IaC checks are added to prevent public storage and broad identity permissions.

Outcome

A production rescan confirms that the bucket is no longer publicly readable and that the deployed image contains the corrected version. A controlled test confirms that the pipeline can deploy with temporary credentials but cannot access unrelated accounts. The organization records residual risks and schedules recurring validation.

Learning points

Severity labels alone do not determine priority. Data exposure and credential scope can dominate a scanner score. Effective treatment combines technical correction, identity control, evidence preservation, automation and repeated validation.

10. Governance, Ethics and Contemporary Practice

Vulnerability activities must respect authorization, privacy and proportionality. Scanning employee devices, customer environments or third-party services without permission may violate law or contract. Testing can expose personal data or create operational outages, so scope, retention, access and notification rules should be defined in advance.

Security teams should avoid blaming individuals for systemic weaknesses. Metrics should encourage learning and timely risk reduction rather than concealment. Useful measures include asset coverage, age of critical findings, time to remediate, recurrence rate, percentage of builds with SBOMs and percentage of deployments using verified artifacts. Metrics must be interpreted carefully: a falling finding count may indicate improvement, or it may indicate reduced scanning.

Artificial intelligence can assist with alert correlation, code review, dependency analysis and prioritization. However, AI-generated remediation may be incorrect, insecure or incompatible with business requirements. Human review, testing, data protection and auditability remain necessary. AI systems themselves introduce model, data, dependency and supply-chain risks.

Contemporary practice is moving toward continuous exposure management, identity-aware controls, automated provenance, confidential computing for selected workloads and policy-as-code. These developments improve visibility and repeatability, but they do not remove the need for sound ownership, secure design and informed judgment.

Best-Practice Checklist

• Maintain an authoritative, continuously updated asset inventory.
• Record ownership, exposure, data classification and lifecycle state.
• Combine scanning with contextual human analysis.
• Prioritize exploitability, exposure, impact and business obligations.
• Define remediation targets and time-limited exceptions.
• Prefer immutable rebuilds and repeatable deployment processes.
• Validate the deployed state, not merely the change process.
• Scan source, dependencies, containers, IaC and cloud configuration.
• Generate and protect SBOMs for releasable artifacts.
• Use short-lived pipeline credentials and least privilege.
• Sign artifacts and verify identity and provenance before deployment.
• Measure coverage and outcomes without encouraging metric manipulation.

Chapter Summary

Vulnerability management is a continuous, risk-based lifecycle beginning with asset discovery and ending with validation and improvement. Scanning identifies possible weaknesses, but prioritization requires exposure, exploitability, business impact and data context. Remediation may involve patching, rebuilding, configuration changes, mitigation, removal or formally accepted residual risk.

DevSecOps embeds security into planning, coding, building, testing, packaging, deployment and operations. IaC requires policy checks, protected state and drift management. Dependency management must include transitive components, while SBOMs provide an inventory for impact analysis. Software supply-chain security adds identity protection, isolated builds, provenance, signing and artifact verification. Effective programs combine automation with ownership, governance, ethical authorization and human judgment.

Key Terms

Vulnerability: A weakness that can be exploited to cause harm.

Threat: A potential cause of an unwanted security event.

Risk: The possibility and consequence of a threat exploiting a weakness.

Asset discovery: Identification and classification of technology resources.

False positive: A reported issue that is not actually present or relevant.

False negative: A weakness that an assessment fails to detect.

Remediation: Correcting or removing a vulnerability.

Mitigation: Reducing risk without fully correcting the underlying weakness.

Risk acceptance: Formal authorization to retain a known risk.

DevSecOps: Integration of security into development and operations practices.

CI/CD: Continuous integration and continuous delivery or deployment.

Infrastructure as code: Definition and management of infrastructure through machine-readable files.

Configuration drift: Difference between intended and deployed configuration.

Dependency: A software component required by another component.

Transitive dependency: A dependency introduced through another dependency.

SBOM: Software bill of materials listing components in an artifact.

Software provenance: Evidence describing an artifact’s origin and build process.

Artifact signing: Applying a verifiable cryptographic identity to a software artifact.

Policy as code: Machine-enforced expression of security or governance rules.

Supply-chain security: Protection of software source, components, tools, builds and releases.

Review Questions

Short Answer Questions

1. Why is asset discovery necessary before vulnerability scanning?
2. Distinguish a vulnerability from a threat and from risk.
3. What is the purpose of an SBOM?
4. Why should pipeline credentials be short-lived?
5. What is the difference between remediation validation and risk validation?

Long Answer Questions

1. Explain the complete vulnerability-management lifecycle and the role of ownership at each stage.
2. Compare network, host, dependency, container and configuration scanning.
3. Discuss how IaC can improve security while also spreading insecure configurations.
4. Explain how DevSecOps changes the security role in a CI/CD lifecycle.
5. Describe a software supply-chain security strategy for a cloud application.

Analytical / Application Questions

1. A critical vulnerability is found on an isolated development server, while a medium-rated configuration issue exposes a production database to the internet. Which should be prioritized and why?
2. Design a validation plan for a container image upgraded to correct a known vulnerable library.
3. A team repeatedly accepts the same vulnerability because patching disrupts releases. Analyze the governance failure and propose technical and managerial controls.

Multiple Choice Questions with Answers

Question 1

Which activity provides the foundation for effective vulnerability management?

A. Asset discovery

B. Risk acceptance

C. Artifact signing

D. Incident reporting

Correct Answer: A. Asset discovery

Question 2

Which finding is most likely to require contextual human review?

A. A scanner reports a vulnerable component that is not present in the deployed image

B. A repository contains a valid source file

C. A build completed successfully

D. A server has an assigned owner

Correct Answer: A. A scanner reports a vulnerable component that is not present in the deployed image

Question 3

Which treatment corrects a vulnerability directly?

A. Installing a security patch

B. Purchasing cyber insurance

C. Accepting the risk

D. Adding a management report

Correct Answer: A. Installing a security patch

Question 4

What is a principal purpose of a CI/CD security gate?

A. To detect unacceptable conditions before deployment

B. To eliminate the need for runtime monitoring

C. To give every developer production administrator access

D. To replace all testing with manual approval

Correct Answer: A. To detect unacceptable conditions before deployment

Question 5

Which statement about infrastructure as code is correct?

A. It can reproduce both secure and insecure configurations

B. It makes access control unnecessary

C. It prevents configuration drift automatically in every environment

D. It proves that a deployment is risk-free

Correct Answer: A. It can reproduce both secure and insecure configurations

Question 6

A transitive dependency is a component that is:

A. Introduced through another dependency

B. Installed only by a cloud provider

C. Used only during incident response

D. Always maintained by the application owner

Correct Answer: A. Introduced through another dependency

Question 7

What does an SBOM primarily provide?

A. An inventory of software components in an artifact

B. A guarantee that the software is vulnerability-free

C. A replacement for access-control policies

D. A record of employee performance

Correct Answer: A. An inventory of software components in an artifact

Question 8

What does artifact signing help establish?

A. Artifact integrity and association with a signing identity

B. That the source code contains no defects

C. That the signer had unlimited authority

D. That the artifact has no vulnerable dependencies

Correct Answer: A. Artifact integrity and association with a signing identity

Question 9

Which practice best reduces risk from CI/CD credentials?

A. Use short-lived credentials with narrowly scoped permissions

B. Store one permanent administrator key in the repository

C. Share a developer password among build runners

D. Print credentials in build logs for auditing

Correct Answer: A. Use short-lived credentials with narrowly scoped permissions

Question 10

Why can a scanner severity score fail to determine the correct remediation order?

A. Business impact and exposure may change the practical risk

B. Scanners never identify software weaknesses

C. All vulnerabilities have identical consequences

D. Cloud assets cannot be classified

Correct Answer: A. Business impact and exposure may change the practical risk