10. DevSecOps, Ethics, Compliance and Governance

Introduction and Context

DevOps integrates development and operations so that software can be delivered rapidly, reliably, and repeatedly. DevSecOps extends this integration by making security a continuous engineering and governance responsibility rather than a final approval activity. The central proposition is simple: software security, privacy, compliance, and ethical accountability must be designed into the delivery system from the beginning and maintained throughout the system life cycle.

This proposition has strategic importance. Modern organizations depend on cloud platforms, open-source components, application programming interfaces, containers, infrastructure as code, managed services, and automated deployment pipelines. These technologies increase delivery capability, but they also create a complex and rapidly changing attack surface. A vulnerable library may enter a build through a transitive dependency; an excessive cloud permission may expose sensitive data; an automated model may make a discriminatory decision; or a deployment pipeline may provide insufficient evidence for an auditor. Security failures are therefore not merely technical incidents. They can become legal, financial, operational, reputational, and ethical failures.

DevSecOps does not mean that every developer becomes a security specialist or that security teams approve every change manually. It means that security responsibilities are distributed appropriately, controls are automated where possible, risk is made visible, and independent oversight is preserved where necessary. The challenge is to combine delivery speed with trustworthy engineering and accountable decision-making.

Learning Objectives

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

1. Explain the relationship between DevOps, DevSecOps, governance, ethics, and compliance.

2. Apply threat modelling to identify assets, trust boundaries, threats, and mitigations.

3. Distinguish secure coding, identity controls, vulnerability management, dependency scanning, and software bills of materials.

4. Design security and compliance controls across the software delivery life cycle.

5. Explain privacy principles, audit evidence, policy as code, and segregation of duties.

6. Evaluate the organizational and ethical consequences of security and compliance decisions.

7. Analyse a DevSecOps implementation and recommend improvements using risk-based reasoning.

From Security Gate to Secure Delivery System

Traditional software delivery often treated security as a sequence of activities performed near the end of a project. A security team might conduct penetration testing before release, while compliance specialists reviewed documentation after deployment. This model created predictable weaknesses. Defects were discovered late, remediation was expensive, and security personnel were perceived as a source of delay. More importantly, many controls were procedural rather than continuous: a document might state that access was reviewed, without demonstrating that access was actually removed when roles changed.

DevSecOps moves security controls toward the points where software is designed, written, built, tested, released, and operated. Security becomes a shared responsibility supported by specialist expertise. A product owner considers security requirements; architects analyse trust boundaries; developers use secure coding practices; platform engineers harden build and runtime environments; security professionals define and validate controls; and managers accept residual risk explicitly when elimination is impractical.

A useful way to view the DevSecOps life cycle is as a feedback system. Requirements create security objectives. Design produces threat models and control decisions. Coding and building generate artefacts that can be scanned. Deployment applies identity and policy controls. Operations produce logs, alerts, and incident evidence. Lessons from incidents and audits are then returned to planning and design. The objective is not merely to prevent every defect, which is unrealistic, but to reduce risk, detect weaknesses early, limit the impact of compromise, and learn systematically.

Security should also be proportionate. A public banking API, an internal prototype, and a non-sensitive reporting dashboard should not necessarily receive identical controls. Risk-based governance considers information sensitivity, business criticality, exposure, threat likelihood, potential impact, regulatory obligations, and the cost and effectiveness of safeguards.

The Core Vocabulary of DevSecOps Governance

Several concepts are essential to professional practice. An asset is something valuable that requires protection, such as data, credentials, services, code, infrastructure, or reputation. A threat is a potential cause of harm, while a vulnerability is a weakness that can be exploited. Risk is the possibility of an adverse outcome, commonly assessed through likelihood and impact. A control is a safeguard intended to prevent, detect, correct, or compensate for a risk.

Authentication establishes who or what an entity is; authorization determines what that entity may do. Least privilege limits permissions to those necessary for an approved task. Separation of duties distributes sensitive responsibilities so that no individual can complete a high-risk action without appropriate independent involvement. Non-repudiation provides evidence that an action was performed by a particular authenticated entity, although technical evidence does not eliminate all questions about human accountability.

A software bill of materials (SBOM) is a structured inventory of software components and their relationships. It may include direct and transitive dependencies, versions, suppliers, and licensing information. A provenance record describes where an artefact came from and how it was produced. Policy as code expresses organizational rules in machine-readable form so that they can be tested and enforced automatically. Audit evidence is reliable, relevant, and sufficiently complete information demonstrating that a control exists and operated as claimed.

These terms should not be confused. A vulnerability scan identifies possible weaknesses; it does not prove that a system is exploitable or that risk is unacceptable. An SBOM identifies components; it does not make those components secure. Authentication verifies identity; it does not justify excessive authorization. Compliance evidence demonstrates conformity to a requirement; it does not necessarily demonstrate good security beyond that requirement.

Threat Modelling as a Design Activity

Threat modelling is a structured method for anticipating how a system could be attacked or misused. It is most valuable early in design, but it should be revisited when architecture, data flows, dependencies, or business use changes. The purpose is not to predict every attack. It is to establish a disciplined conversation about what must be protected, from whom, and by which controls.

A practical threat-modelling process begins by defining scope. The team identifies system boundaries, important assets, users, external services, data stores, and trust boundaries. A data-flow diagram can show how information moves between a browser, API gateway, service, database, message queue, identity provider, and third-party service. Each transition across a trust boundary deserves particular attention.

The team then asks structured questions. One widely used mnemonic is STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. STRIDE is not a complete threat universe, but it provides a useful starting point. Teams may supplement it with abuse cases, misuse cases, attack trees, privacy threat analysis, supply-chain analysis, and scenario-based workshops.

Threats are prioritized according to factors such as exploitability, affected assets, exposure, business impact, detectability, and regulatory significance. Possible responses include eliminating the feature, reducing likelihood, reducing impact, transferring some risk contractually or through insurance, accepting residual risk, or monitoring the threat. Acceptance should be explicit, time-bounded where appropriate, and approved by an accountable risk owner.

Threat modelling is ineffective when treated as a document produced once for an audit. It should influence architecture decisions, backlog items, test cases, monitoring requirements, and release criteria. For example, if a model identifies token replay as a significant threat, the resulting controls may include short token lifetimes, audience validation, secure storage, key rotation, replay detection, and tests that verify these behaviours.

Secure Coding and Software Supply-Chain Assurance

Secure coding translates security requirements into implementation practices. Common concerns include injection, broken access control, insecure deserialization, improper error handling, weak cryptography, inadequate input validation, unsafe file handling, race conditions, and leakage of secrets through logs or repositories. Secure coding is not achieved by memorizing a list of defects. Developers must understand the security properties expected from the system and use frameworks, libraries, and design patterns that support those properties.

Input should be validated according to context, but validation alone is not a substitute for parameterized queries, output encoding, authorization checks, and safe APIs. Cryptographic algorithms should be selected from approved standards and implemented through well-maintained libraries rather than custom code. Secrets should be stored in dedicated secret-management systems, accessed through controlled identities, rotated according to risk, and excluded from source code and build logs.

Peer review, secure coding standards, static application security testing, dynamic testing, interactive testing, fuzzing, and targeted penetration testing provide different forms of assurance. None is sufficient alone. Automated tools produce false positives and false negatives, while manual testing provides depth but is slower and dependent on expertise. Findings should be triaged according to exploitability and impact rather than scanner severity alone.

The software supply chain requires special attention because modern applications often incorporate code not written by the organization. Dependency management should use approved repositories, version constraints, lock files, update automation, license review, integrity verification, and monitoring for newly disclosed vulnerabilities. Build systems should be isolated, credentials minimized, and artefacts signed or otherwise associated with verifiable provenance. Reproducible builds and protected source-control branches can strengthen confidence that released software corresponds to reviewed source.

An SBOM supports vulnerability response by allowing an organization to ask which products contain an affected component. It also supports license governance and supplier analysis. However, an SBOM has value only when it is accurate, current, machine-readable, linked to specific artefacts, and incorporated into operational processes. Organizations must establish ownership for responding to component vulnerabilities, including decisions about patching, compensating controls, temporary acceptance, and customer notification.

Identity, Access, and Secrets in Automated Environments

Identity is the foundation of both security and governance. In DevSecOps, identities belong not only to human users but also to services, pipelines, workloads, devices, and automation agents. Shared accounts obscure responsibility and weaken investigation. Strong practice uses individually attributable human identities, workload identities where feasible, multifactor authentication for sensitive access, centralized lifecycle management, and regular review of entitlements.

Authorization should be explicit and contextual. Role-based access control can assign permissions according to job functions, while attribute-based approaches can consider resource classification, environment, location, device posture, or transaction context. Privileged access should be temporary where practical, recorded, and subject to approval or independent monitoring. Production access for developers may be restricted, brokered, or granted through controlled emergency procedures rather than permanently assigned.

The principle of least privilege is necessary but not sufficient. Permissions should also be separated across environments and functions. A pipeline that can modify source code, approve its own change, deploy to production, and delete audit logs represents a concentrated risk. Short-lived credentials, workload identity federation, protected deployment environments, and immutable logs reduce this risk.

Access reviews should be evidence-based. An organization should be able to show who had access, why access was granted, who approved it, when it was last reviewed, and when it was revoked. Joiner, mover, and leaver processes are particularly important because stale permissions frequently arise when employees change roles or leave.

Vulnerability Management, Scanning, and Evidence

Vulnerability management is a continuous risk process rather than a scanning event. It includes discovery, validation, prioritization, remediation, verification, exception handling, and reporting. Scanning may cover source code, open-source dependencies, container images, infrastructure as code, cloud configurations, running applications, and hosts. The appropriate combination depends on system architecture and risk.

A vulnerability’s severity score is only one input to prioritization. Teams should consider whether the vulnerable component is present in the deployed artefact, reachable, exploitable in the organization’s configuration, exposed to the internet, associated with sensitive data, and subject to an active exploitation campaign. A lower-scored weakness in an exposed authentication service may deserve faster action than a higher-scored issue in unreachable test code.

Remediation service-level objectives should be risk-based and measurable. Exceptions should record the vulnerability, affected assets, rationale, compensating controls, owner, expiry date, and approval authority. A permanent exception without review is usually a hidden acceptance of risk. Verification is essential: closing a ticket is not equivalent to proving that the vulnerable component was removed or the control became effective.

Audit evidence should be generated as a by-product of engineering activity. Examples include signed build records, pull-request approvals, test results, access-review records, deployment logs, change tickets, vulnerability dispositions, configuration snapshots, incident reports, and policy evaluation results. Evidence must be protected from unauthorized alteration and retained according to legal, contractual, and organizational requirements. Excessive evidence can also create privacy and storage problems; organizations should collect what is necessary and define retention periods.

Privacy, Ethics, and Responsible Automation

Security protects information and systems from unauthorized harm, while privacy concerns the legitimate and fair collection, use, disclosure, retention, and deletion of information about people. A system can be secure but invasive, or privacy-conscious but technically vulnerable. DevSecOps therefore needs both security engineering and privacy-by-design practices.

Privacy analysis begins with purpose specification and data minimization. Teams should identify what personal data is collected, why it is needed, where it flows, who can access it, how long it is retained, and how individuals’ rights are supported under applicable law. Sensitive data should be classified, encrypted appropriately, masked in non-production environments, and excluded from logs unless there is a justified operational need. Test data should be synthetic or properly de-identified where feasible.

Ethical responsibility extends beyond legal compliance. Engineers should consider foreseeable misuse, unequal impacts, deceptive design, unjustified surveillance, accessibility, safety, and the consequences of failure. A technically lawful feature may still undermine user autonomy or distribute risk unfairly. Automated decision systems require particular care regarding data quality, explainability appropriate to the context, human review, bias evaluation, and appeal mechanisms.

Compliance frameworks and laws vary by jurisdiction and sector. Depending on the organization, relevant obligations may include data protection and privacy law, financial or health-sector requirements, contractual security clauses, records obligations, and recognized control frameworks. Compliance should be treated as a set of obligations to interpret and operationalize, not as a checklist detached from engineering reality. Legal counsel, compliance officers, security professionals, product leaders, and affected stakeholders may all contribute to interpretation.

Governance, Policy as Code, and Segregation of Duties

Governance establishes who may decide, what must be controlled, how exceptions are handled, and how accountability is demonstrated. Effective governance aligns business objectives, risk appetite, technical controls, and oversight. It does not require every technical decision to be escalated to senior management. Instead, decision rights should be clear and proportionate.

Policy as code can express rules such as: production storage must not be publicly accessible; encryption must be enabled; deployments require an approved change; containers must not run with excessive privileges; or infrastructure must be deployed only in approved regions. These rules can be evaluated during pull requests, builds, deployment, and runtime monitoring. Automated policies improve consistency and speed, but they must be versioned, tested, reviewed, and governed. A defective policy can block legitimate delivery or create a false sense of security.

Segregation of duties is a governance control designed to reduce fraud, error, abuse, and undisclosed conflicts. In a delivery pipeline, it may mean that the person who writes a sensitive change cannot be the only person who approves and deploys it. It may also mean that security exceptions require approval by a risk owner independent of the implementer. The appropriate design depends on organizational size and risk. Small teams may use compensating controls such as peer review, immutable logs, automated approvals based on tested conditions, or retrospective independent review.

Governance must avoid becoming ceremonial. If a control is impossible to follow under normal delivery conditions, teams will bypass it. Controls should therefore be tested for usability, measured for effectiveness, and revised when they generate excessive friction without reducing meaningful risk. Exceptions should be visible rather than hidden in informal channels.

An Illustrative Case: Securing a Regulated Payments Platform

Background

This illustrative case concerns PayFlow, a fictional organization operating a cloud-based business-to-business payments platform. The platform uses microservices, managed databases, container orchestration, third-party identity services, and several open-source libraries. The organization has grown quickly and must satisfy contractual security requirements from major customers while preparing for an external audit.

Situation and Problem

PayFlow’s delivery team deploys several times each day. A security review discovers that production credentials are stored in a pipeline configuration file, developers retain standing access to production, dependency inventories are incomplete, and audit evidence is assembled manually at the end of each quarter. A recent vulnerability in a transitive library cannot be located reliably because teams do not know which deployed services contain it. The business fears that introducing approval gates will reduce release speed.

Analysis

The weaknesses are interconnected. Secret exposure is an identity and pipeline design problem, not only a coding problem. Standing production access violates least privilege and weakens segregation of duties. Incomplete dependency information increases incident response time. Manual evidence collection raises the risk of inaccurate records and consumes engineering capacity. The central issue is the absence of an integrated control model.

Threat modelling identifies payment data, customer identity data, credentials, deployment infrastructure, and service availability as high-value assets. Important scenarios include credential theft, unauthorized payment modification, dependency compromise, privilege escalation, and disclosure through logs. Risk analysis shows that the organization needs stronger preventive controls but also rapid detection and recovery capabilities.

Approach and Strategy

PayFlow adopts a staged DevSecOps programme. First, it moves secrets to a managed vault, replaces long-lived pipeline credentials with short-lived workload identities, and rotates exposed credentials. Second, it introduces protected branches, mandatory peer review for sensitive services, and automated checks for secret leakage and insecure infrastructure configuration. Third, the build process generates an SBOM for every release and stores it with signed artefact metadata. A vulnerability service correlates SBOM data with deployed versions and creates prioritized work items.

Production access is brokered through temporary, logged privileges. Developers can request emergency access, but approval and post-event review are required. Deployment policies verify that the artefact originated from an approved build, required tests passed, the image contains no unresolved critical finding without an approved exception, and the target environment satisfies configuration rules. Security and compliance teams define policies and review results, while product and engineering leaders remain responsible for business risk decisions.

Privacy controls are added by masking customer data in test environments, limiting log content, defining retention periods, and documenting data flows. Audit evidence is collected automatically from source control, the build platform, identity system, deployment service, and policy engine. A dashboard shows control status, overdue vulnerabilities, expired exceptions, privileged access events, and evidence freshness.

Outcome

The organization retains frequent deployment while improving traceability and reducing manual audit preparation. It can identify affected services when a dependency vulnerability is announced and can demonstrate who approved and deployed a release. Some friction remains: policy exceptions require disciplined review, and teams must maintain accurate ownership information. The programme therefore includes regular control reviews and training rather than assuming automation alone will solve governance problems.

Learning Points

The case illustrates that DevSecOps is an operating model, not a collection of scanners. Identity, supply-chain assurance, privacy, policy automation, evidence, and accountability reinforce one another. It also demonstrates that segregation of duties need not require slow, universal manual approval; risk-sensitive automation and independent oversight can provide a better balance.

Challenges and Common Failure Patterns

A frequent failure is tool accumulation. Organizations purchase scanners but do not define ownership, triage processes, remediation targets, or exception rules. The result is alert fatigue and superficial compliance. Another failure is measuring activity rather than outcomes—for example, counting scans instead of measuring time to remediate exploitable weaknesses or the proportion of releases with verifiable provenance.

Teams may also over-rely on severity scores, ignore transitive dependencies, or assume that a passing build means a secure application. Static analysis can miss design flaws; dynamic testing may not cover authorization logic; and threat models can become outdated. Controls that operate only in a development environment may not reflect production configuration.

Governance can fail through excessive centralization. If a security group becomes the only body permitted to make ordinary decisions, delivery teams may evade the process. The opposite failure is uncontrolled decentralization, in which every team interprets policy differently. A federated model is often effective: central functions establish standards, platforms, reusable controls, and assurance; product teams own implementation and day-to-day risk; independent oversight tests effectiveness.

Other important limitations include incomplete asset inventories, poor ownership data, inaccurate SBOMs, weak logging, untested recovery procedures, and privacy risks created by collecting excessive telemetry. Automated policy enforcement can also produce inequitable outcomes if its rules embed unjustified assumptions. Human review remains necessary for ambiguous, high-impact, or exceptional decisions.

Current Developments and Strategic Direction

DevSecOps is increasingly connected with software supply-chain security, cloud security posture management, zero-trust architectures, confidential computing, identity-centric infrastructure, and continuous control monitoring. Organizations are seeking stronger evidence that software was built from authorized source using protected processes. Signed artefacts, provenance attestations, isolated build environments, and verifiable deployment records are becoming more significant.

Artificial intelligence introduces both opportunities and risks. AI-assisted coding can improve productivity but may generate insecure patterns, reproduce licensing concerns, or expose confidential prompts and code. AI-based security tools can prioritize findings and detect anomalies, but their outputs require validation. Organizations should define approved uses, data-handling rules, human accountability, testing requirements, and procedures for correcting harmful or inaccurate outputs.

Policy automation is also evolving from simple configuration checks toward continuous evaluation of identities, data flows, workloads, and business context. The strategic objective is not total automation. It is dependable automation for repeatable controls combined with informed human judgment for risk acceptance, ethical questions, novel threats, and decisions affecting people.

Best-Practice Principles for Professional Practice

A mature DevSecOps programme generally follows these principles:

• Establish security, privacy, and compliance requirements during planning and architecture.
• Use threat modelling to connect business assets and abuse scenarios with concrete controls.
• Make identities individual, attributable, least-privileged, and preferably short-lived.
• Protect secrets and separate development, testing, and production environments.
• Combine secure coding, peer review, automated testing, scanning, and focused manual assessment.
• Maintain accurate SBOMs and provenance records for released artefacts.
• Prioritize vulnerabilities by contextual risk and verify remediation.
• Express repeatable controls as tested, versioned policy as code.
• Generate trustworthy audit evidence continuously and protect its integrity.
• Apply privacy by design, data minimization, retention limits, and responsible-use review.
• Preserve segregation of duties for high-impact actions while using proportionate compensating controls.
• Treat exceptions as visible, time-bound risk decisions rather than permanent bypasses.
• Measure control effectiveness and business outcomes, not merely tool usage.
• Review controls after incidents, architectural changes, regulatory developments, and emerging threats.

Chapter Summary

DevSecOps integrates security, privacy, compliance, and governance into the software delivery life cycle. Its foundation is shared responsibility supported by specialist expertise, automation, risk-based decision-making, and continuous feedback. Threat modelling identifies assets, trust boundaries, abuse scenarios, and appropriate mitigations. Secure coding and software supply-chain practices reduce defects and improve confidence in dependencies, artefacts, and provenance. Identity controls, least privilege, temporary access, and segregation of duties preserve accountability in automated environments.

Vulnerability management requires discovery, contextual prioritization, remediation, verification, and controlled exceptions. SBOMs improve component visibility but must be accurate and operationally connected to response processes. Privacy and ethics extend beyond technical security and require consideration of purpose, minimization, fairness, autonomy, and foreseeable misuse. Policy as code and continuously generated audit evidence can improve consistency and assurance, provided that policies are tested and evidence is trustworthy. Effective governance balances delivery speed with independent oversight, ethical responsibility, regulatory obligations, and explicit ownership of residual risk.

Key Terms

Asset: Anything of value that requires protection.

Threat: A potential cause of harm to an asset or system.

Vulnerability: A weakness that may be exploited.

Risk: The possibility of an adverse outcome, considered through likelihood and impact.

Control: A preventive, detective, corrective, or compensating safeguard.

Threat modelling: A structured analysis of assets, trust boundaries, threats, and mitigations.

Least privilege: Granting only the access necessary for an authorized task.

Segregation of duties: Dividing sensitive responsibilities to reduce abuse, error, or fraud.

Authentication: Verification of an entity’s identity.

Authorization: Determination of the actions an authenticated entity may perform.

Software bill of materials: A structured inventory of software components and dependencies.

Software provenance: Evidence describing the origin and production history of an artefact.

Policy as code: Machine-readable rules that can be tested and enforced automatically.

Vulnerability management: The process of discovering, prioritizing, remediating, and verifying weaknesses.

Secure coding: Development practices that prevent or reduce exploitable software defects.

Privacy by design: Integrating privacy protections into system design and operation.

Audit evidence: Reliable information demonstrating that a control exists and operated as required.

Residual risk: Risk remaining after safeguards have been applied.

Compensating control: An alternative safeguard that addresses a risk when the preferred control is unavailable.

Review Questions

Short Answer Questions

1. What distinguishes DevSecOps from a traditional end-of-project security review?

2. Why is an SBOM useful during response to a newly disclosed dependency vulnerability?

3. Differentiate authentication from authorization.

4. What information should a risk-based vulnerability exception contain?

5. Why is privacy not equivalent to information security?

Long Answer Questions

1. Explain how threat modelling can influence architecture, coding, testing, monitoring, and release decisions.

2. Discuss the role of identity, least privilege, temporary access, and segregation of duties in an automated DevOps pipeline.

3. Examine the relationship between secure coding, dependency management, SBOMs, provenance, and software supply-chain assurance.

4. Explain how policy as code and continuously generated audit evidence can improve governance, including their limitations.

5. Discuss the ethical and regulatory responsibilities involved in collecting personal data and deploying AI-assisted software systems.

Analytical / Application Questions

1. A team discovers that a production pipeline account can alter source code, approve pull requests, deploy releases, and delete logs. Analyse the risks and propose a redesigned control model.

2. An organization’s scanner reports hundreds of high-severity dependency findings, but only a small number affect internet-facing production services. Design a prioritization and exception process.

3. A healthcare application uses real customer records in a test environment and logs full request payloads for debugging. Apply DevSecOps, privacy, and governance principles to recommend corrective actions.

22. Multiple Choice Questions with Answers

Question 1

Which activity best represents the primary purpose of threat modelling?

A. Counting the number of vulnerabilities reported by scanners

B. Identifying assets, attack scenarios, trust boundaries, and appropriate mitigations

C. Replacing all manual security testing with automation

D. Proving that a system cannot be compromised

Correct Answer: B. Identifying assets, attack scenarios, trust boundaries, and appropriate mitigations

Question 2

A vulnerability has a high severity score but exists only in unreachable test code. An internet-facing authentication service has a lower-scored vulnerability that is actively exploitable. What is the best prioritization decision?

A. Remediate the higher-scored issue automatically

B. Ignore both findings until the next audit

C. Prioritize the exposed, exploitable authentication weakness based on contextual risk

D. Prioritize the issue affecting the largest source-code file

Correct Answer: C. Prioritize the exposed, exploitable authentication weakness based on contextual risk

Question 3

What does an SBOM primarily provide?

A. A guarantee that all software components are secure

B. An inventory of software components and their relationships

C. A replacement for access control

D. A legal approval to use open-source software

Correct Answer: B. An inventory of software components and their relationships

Question 4

Which design most clearly violates segregation of duties?

A. A developer submits a change and another engineer reviews it

B. A security team defines deployment policies and product teams implement them

C. A pipeline account writes code, approves its own change, deploys it, and deletes logs

D. An emergency production access request receives retrospective review

Correct Answer: C. A pipeline account writes code, approves its own change, deploys it, and deletes logs

Question 5

Why are short-lived workload identities preferred to shared, long-lived pipeline credentials?

A. They eliminate the need for authorization

B. They improve attribution and reduce the period during which stolen credentials are useful

C. They prevent all software vulnerabilities

D. They make audit evidence unnecessary

Correct Answer: B. They improve attribution and reduce the period during which stolen credentials are useful

Question 6

Which statement best describes policy as code?

A. A document explaining security principles in natural language only

B. Machine-readable rules that can be tested and enforced automatically

C. A list of vulnerabilities found in production

D. A manual approval process conducted by auditors

Correct Answer: B. Machine-readable rules that can be tested and enforced automatically

Question 7

A team closes a vulnerability ticket after changing a version number in a manifest. What should happen next?

A. The issue should be considered permanently resolved without further action

B. The organization should verify that the deployed artefact no longer contains the vulnerable component

C. The entire application should be deleted

D. The finding should be hidden from audit reports

Correct Answer: B. The organization should verify that the deployed artefact no longer contains the vulnerable component

Question 8

Which practice best reflects privacy by design?

A. Collecting all available data in case it becomes useful later

B. Retaining production records indefinitely for convenience

C. Defining purpose, minimizing collection, protecting access, and setting retention limits

D. Relying only on a privacy notice after deployment

Correct Answer: C. Defining purpose, minimizing collection, protecting access, and setting retention limits

Question 9

Why is automated scanning insufficient as the sole security assurance method?

A. Scanners cannot produce any useful information

B. Automated tools may miss design flaws and produce false positives or false negatives

C. Manual testing is always cheaper and faster

D. Scanning prevents organizations from using version control

Correct Answer: B. Automated tools may miss design flaws and produce false positives or false negatives

Question 10

In the PayFlow case, which combination most directly improves supply-chain visibility and response?

A. More frequent unreviewed deployments and shared credentials

B. An SBOM for each release linked to deployed artefacts and vulnerability response

C. Manual quarterly documentation without component inventories

D. Removing all third-party dependencies without analysis

Correct Answer: B. An SBOM for each release linked to deployed artefacts and vulnerability response