3. Risk Management, Governance and Compliance

Introduction and Context

DevSecOps is often described as the integration of security into development and operations. That description is accurate but incomplete. At an organizational level, DevSecOps is also a system for translating business obligations and risk decisions into repeatable technical controls. A payment company, a hospital, a government agency and an online retailer may use similar delivery tools, yet their security priorities, regulatory duties, tolerance for disruption and evidence requirements will differ substantially.

Risk management, governance and compliance provide the strategic structure within which pipeline security operates. Risk management asks what could harm the organization, how probable and consequential that harm might be, and what treatment is justified. Governance assigns authority, accountability and decision rights. Compliance establishes obligations arising from laws, contracts, standards and internal policies. A mature DevSecOps program connects all three to software delivery without reducing security to a final approval gate.

The central challenge is translation. Business language refers to material loss, customer trust, privacy, resilience and regulatory exposure. Engineering language refers to source repositories, build agents, dependencies, identities, deployment environments and control failures. Effective governance creates traceable relationships between these languages: a business risk is expressed as a policy, the policy becomes a control, the control is automated where feasible, and its operation produces evidence.

This chapter examines that translation using the NIST Cybersecurity Framework (CSF), NIST Secure Software Development Framework (SSDF), ISO/IEC 27001, SOC 2 and OWASP SAMM. These frameworks should not be treated as interchangeable checklists. Each has a different purpose, audience and assurance model. Their value increases when they are combined through a coherent control architecture and a disciplined approach to exceptions and risk acceptance.

Learning Objectives

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

1. Distinguish risk management, governance, compliance and assurance in a DevSecOps context.

2. Explain how NIST CSF, NIST SSDF, ISO/IEC 27001, SOC 2 and OWASP SAMM support different organizational needs.

3. Translate business risks and regulatory obligations into pipeline policies and technical controls.

4. Design accountability, evidence, exception and risk-acceptance processes.

5. Evaluate the strengths and limitations of preventive, detective and responsive controls.

6. Apply governance principles to a realistic software delivery case.

7. Identify common control-design failures and propose improvements.

From Business Exposure to Pipeline Control

A risk is commonly expressed as the effect of uncertainty on objectives. In security practice, risk is often analyzed through the relationship between a threat, a vulnerability, an affected asset or process, and a consequence. A vulnerable third-party library is not automatically a business risk of the same magnitude in every system. Its significance depends on exploitability, exposure, privilege, data sensitivity, compensating controls and the importance of the service.

A useful translation chain is:

Business objective → risk scenario → security requirement → policy → control → evidence → decision.

For example, an organization may have the objective of protecting customer payment information. A risk scenario could be the release of code that exposes payment data through an injection flaw. The security requirement may require peer review, automated testing, protected branches and controlled production deployment. A policy can specify that high-severity findings blocking payment-service releases must be remediated or formally accepted. Controls include secret scanning, static analysis, dynamic testing, approval rules and deployment authorization. Evidence consists of scan records, pull-request history, test results, approvals and exception records.

This chain prevents two opposite errors. The first is vague governance: statements such as “security must be considered” that cannot be tested. The second is control accumulation: implementing numerous scanners without knowing which business risks they address. A control is valuable when its purpose, owner, operating condition and evidence are understood.

Important terminology

Risk appetite is the amount and type of risk an organization is willing to pursue or retain in achieving its objectives. Risk tolerance is the acceptable variation around a specific objective or risk threshold. Inherent risk exists before controls are applied; residual risk remains after controls and treatments. Risk treatment may involve avoiding, reducing, transferring or accepting risk.

Governance concerns direction, oversight, accountability and decision rights. Compliance is adherence to applicable requirements, while assurance is justified confidence that controls are suitably designed and operating effectively. A compliant process may still be poorly designed, and a strong security practice may exceed minimum compliance requirements.

A control objective states what a control is intended to achieve. A control activity is the action or mechanism used to achieve it. A control owner is accountable for the control’s operation and performance. A control operator performs the activity, although the owner and operator may be different. Evidence is information demonstrating that a control was designed, performed or effective during a defined period.

An exception is an approved deviation from a policy or control requirement. Risk acceptance is a decision by an authorized party to retain a known risk, normally within defined limits and for a defined period. Acceptance is not the same as ignoring a risk; it requires analysis, authority, conditions and review.

Frameworks as Complementary Governance Instruments

NIST Cybersecurity Framework

The NIST Cybersecurity Framework is an outcomes-oriented structure for managing cybersecurity risk. Its familiar functions—Govern, Identify, Protect, Detect, Respond and Recover—help organizations describe desired outcomes rather than prescribe one particular tool. The Govern function emphasizes organizational context, risk strategy, roles, policy and oversight. The other functions connect those decisions to asset understanding, safeguards, monitoring, incident handling and resilience.

In a DevSecOps environment, the CSF can organize a security program around the software lifecycle. Identify includes inventories of applications, repositories, dependencies, data and delivery environments. Protect includes secure coding, identity management, protected branches and hardened build infrastructure. Detect includes monitoring for anomalous pipeline behavior, unauthorized changes and vulnerable components. Respond and Recover include containment, rollback, credential rotation, communication and restoration.

The CSF is particularly useful for executive communication and risk profiling. It does not, by itself, provide all the detailed practices needed to implement secure software development. For that purpose, NIST SSDF is more specific.

NIST Secure Software Development Framework

NIST SSDF organizes secure software development practices into four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities. The framework emphasizes that security must be planned and embedded in organizational processes rather than added only during testing.

In pipeline terms, preparing the organization may involve security roles, developer training, approved tools, risk criteria and supplier expectations. Protecting software includes access control to code and build systems, protection of release integrity and management of software components. Producing well-secured software includes threat modeling, secure design, code review, testing and defect remediation. Responding to vulnerabilities includes receiving reports, analyzing impact, communicating with stakeholders and issuing fixes.

SSDF is valuable because it links practices to software producers and consumers. It also supports procurement and supplier conversations. However, it does not replace an enterprise risk-management system or an audit standard. Organizations must still determine priorities, ownership and evidence.

ISO/IEC 27001

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS). Its logic is risk-based: the organization defines context, assesses risks, selects treatments and maintains documented information supporting its management system. Annex A provides a reference set of controls, but certification depends on the ISMS and its operation, not merely on the presence of individual technologies.

For DevSecOps, ISO/IEC 27001 encourages integration with organizational processes. Secure development, supplier relationships, access control, change management, logging, incident management and business continuity should be governed as parts of an information security system. A pipeline control is therefore not an isolated engineering preference; it may support a formally documented risk treatment and be subject to internal audit or certification assessment.

The strength of ISO 27001 is its management-system discipline and continual-improvement orientation. Its limitation is that it does not prescribe the precise scanning threshold, branching model or deployment tool an organization must use. Those decisions remain contextual.

SOC 2

SOC 2 is an attestation approach based on Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. A service organization defines its system and relevant criteria, describes controls, and obtains an independent examination. A Type I report generally addresses the design of controls at a point in time, whereas a Type II examination evaluates operating effectiveness over a period.

DevSecOps evidence commonly supports SOC 2 controls concerning logical access, change management, vulnerability management, incident response, monitoring and availability. For example, a control may require that production changes are authorized, tested and traceable to an approved request. Evidence may include pull requests, automated test results, deployment records and access reviews.

SOC 2 is not a universal security certification and should not be represented as proof that a product is free from vulnerabilities. Its scope, system description, criteria and control design matter greatly. A narrow scope can produce a valid report while excluding important systems or activities.

OWASP SAMM

The OWASP Software Assurance Maturity Model (SAMM) is an open model for assessing and improving software assurance maturity. It addresses governance, design, implementation, verification and operations, with practices that organizations can use to establish a baseline and plan progressive improvement.

SAMM is especially helpful for engineering-led maturity assessments. It can reveal, for example, that a company performs automated scanning but lacks threat modeling, security requirements, vulnerability intelligence, incident learning or secure architecture review. Unlike a compliance audit, a SAMM assessment is primarily a capability-improvement exercise. Its practical value lies in prioritizing achievable improvements rather than claiming that a single tool establishes maturity.

Using the frameworks together

The frameworks answer different questions:

• NIST CSF: What cybersecurity outcomes and risk-management activities should the organization govern?
• NIST SSDF: What practices help produce and maintain secure software?
• ISO/IEC 27001: How can an organization operate and continually improve a risk-based information security management system?
• SOC 2: How can a service organization demonstrate that scoped controls meet relevant trust criteria over time?
• OWASP SAMM: How mature are software assurance capabilities, and how should they improve?

A mapping matrix can connect them without pretending they are identical. One row might represent “production changes are authorized and traceable.” The row can map to governance and protect outcomes in the CSF, secure software and organizational practices in SSDF, change and access controls in an ISMS, change-management criteria in SOC 2, and governance or operations practices in SAMM. The matrix should identify the actual organizational control, its owner, implementation locations and evidence rather than merely listing framework references.

Designing Governance for the Delivery System

Governance becomes meaningful when it establishes decision rights. A senior security officer may own policy, a product team may own application risk, a platform team may operate pipeline controls, and an audit or assurance function may independently evaluate evidence. These roles must be separated sufficiently to avoid self-approval of significant risk, while remaining practical enough to support delivery.

A responsibility assignment matrix can clarify who is responsible for performing a control, accountable for its outcome, consulted on technical or regulatory questions, and informed of material results. Accountability should follow authority. It is unreasonable to hold a team accountable for remediation when it cannot prioritize work, access evidence or obtain compensating controls.

Governance should also define risk criteria. Severity alone is insufficient. A critical vulnerability in an isolated test utility may be less urgent than a medium-severity weakness in an internet-facing service handling regulated data. Criteria may consider exploitability, exposure, asset criticality, data classification, compensating controls, exploit evidence and time since discovery.

Policy should distinguish mandatory requirements from guidance. A policy might require that production artifacts be traceable to reviewed source and reproducible build inputs. A standard may define minimum review and testing requirements. A procedure may explain how teams implement those requirements in a particular platform. This hierarchy allows organizational consistency without forcing every team to use identical tools.

Making Controls Operate in the Pipeline

Pipeline controls can be preventive, detective or corrective. Preventive controls stop or restrict an action, such as requiring multi-factor authentication or blocking deployment when an artifact is unsigned. Detective controls identify conditions, such as dependency scanning, audit logging or drift monitoring. Corrective controls reduce impact after detection, such as rollback, credential revocation and vulnerability remediation.

Controls should be placed according to risk and delivery context. Typical control points include:

• Planning: security requirements, data classification, threat modeling and risk assessment.
• Source management: protected branches, code-owner review, signed commits where appropriate and secret detection.
• Build: isolated runners, dependency verification, reproducible inputs, static analysis and artifact signing.
• Test and verification: unit and integration security tests, dynamic analysis, infrastructure-as-code validation and policy checks.
• Release: approval rules, vulnerability thresholds, provenance verification, segregation of duties and deployment authorization.
• Operations: runtime monitoring, incident response, vulnerability intelligence, rollback capability and periodic access review.

Automation is powerful but not infallible. A scanner may produce false positives, miss business-logic weaknesses or fail because of an incorrectly configured pipeline. Therefore, control design should specify failure behavior, ownership of findings, service-level expectations and manual review conditions. “The tool ran” is not equivalent to “the risk was controlled.”

Evidence should be designed at the same time as the control. Useful evidence is attributable, time-stamped, protected from unauthorized alteration, retained for the required period and understandable to a reviewer. A dashboard showing a green status without underlying records is weak evidence. Stronger evidence links the policy requirement to a specific repository, build, artifact, approver, test result and deployment.

Exceptions and Risk Acceptance

Absolute policies are attractive but unrealistic. Emergency changes, legacy components, supplier constraints and false positives create situations in which a requirement cannot be met immediately. An uncontrolled exception process, however, silently converts policy into optional guidance.

A sound exception record should identify the requirement, affected system, reason for deviation, risk assessment, compensating controls, accountable owner, approving authority, start date, expiry date and remediation plan. Exceptions should be time-limited and reviewed. Repeated renewals may indicate that the policy is impractical, the remediation is underfunded or the organization has normalized unacceptable risk.

Risk acceptance should be proportionate to impact. A product manager may accept a low residual risk within delegated authority, whereas acceptance of a substantial risk affecting regulated data may require executive or risk-committee approval. The authority should not be based merely on organizational seniority; it should reflect knowledge, accountability and the ability to allocate resources.

Emergency change processes deserve particular care. An emergency may justify expedited approval, but not the absence of evidence. The organization can require retrospective review, enhanced monitoring, limited deployment scope and a deadline for permanent remediation. The purpose is to preserve resilience without creating a permanent bypass channel.

Applied Case: Governing a Regulated Payments Platform

Background

The following is an illustrative case. MeridianPay operates a cloud-based payment-processing platform used by business customers. Its development teams deploy several times each day. The organization is preparing for an independent SOC 2 examination, maintains an ISO 27001-aligned ISMS, and has adopted NIST SSDF practices for its product teams. Its board has identified customer trust and service availability as strategic priorities.

Situation and problem

A dependency scanner identifies a high-severity vulnerability in a library used by the payment API. The vulnerability is exploitable under a particular configuration, but the affected code path is not currently enabled. The vendor has released a patch, yet applying it requires compatibility testing. The product team wants to deploy a customer-requested feature immediately. The release pipeline blocks the deployment because the library finding exceeds the configured threshold.

At the same time, an audit review finds that several previous exceptions lack expiry dates and that deployment evidence is stored in separate tools without a consistent release identifier. Management is concerned that the organization has both excessive blocking and inadequate governance.

Analysis

The vulnerability must be assessed in context. Relevant factors include internet exposure, whether the vulnerable function is reachable, the sensitivity of payment data, exploit availability, compensating controls, patch confidence and the time required for testing. The organization should not treat the scanner’s severity as the final business decision, but neither should it dismiss the finding because the vulnerable path is currently disabled.

The control objective is to prevent unauthorized or unacceptably risky software from reaching production while allowing authorized decisions under exceptional circumstances. The evidence objective is to demonstrate what was found, who assessed it, what decision was made, which controls were applied and when remediation occurred.

Approach and solution

MeridianPay first confirms the vulnerability through software composition analysis and checks whether the affected function is reachable in its deployment configuration. The security architect documents the analysis and identifies compensating controls: restricted network paths, runtime monitoring, configuration validation and a short remediation window.

The product owner submits a time-limited exception. The request identifies the affected service, vulnerability, business justification, residual risk, compensating controls and a committed patch date. Because payment data is involved, approval is escalated to the designated risk authority rather than being approved solely by the delivery team.

The pipeline is not permanently disabled. Instead, a controlled release mechanism permits the specific version to proceed only when the approved exception identifier is linked to the build and deployment. The exception expires after a short period, and the pipeline blocks later releases if remediation evidence is absent. The deployment receives enhanced monitoring, and the security team schedules a review after the patch is tested.

MeridianPay then improves its governance architecture. It creates a common release identifier across source control, build records, scan results, approvals and deployment logs. It establishes mandatory expiry dates and automated reminders for exceptions. It maps the control to its SSDF practices, ISO 27001 risk treatment, SOC 2 change-management evidence and relevant SAMM improvement activities.

Outcome

The feature is released without converting a temporary decision into a general bypass. The vulnerability is patched within the approved window, and the exception is closed with evidence. During the subsequent examination, reviewers can reconstruct the decision and verify operation of the change-control process. The organization also discovers that exception aging is a useful management metric, not merely an audit concern.

Learning points

The case illustrates five principles. First, risk-based decisions require contextual analysis. Second, preventive automation should have a governed override path rather than an informal workaround. Third, exception authority must match business impact. Fourth, evidence architecture is part of control architecture. Finally, recurring exceptions are signals about engineering capacity, policy quality or risk appetite.

Challenges, Limitations and Common Mistakes

A frequent mistake is framework shopping: selecting controls because they appear in a standard rather than because they address a material risk. Another is treating certification or an attestation report as proof of absolute security. Frameworks provide structure and assurance within scope; they do not eliminate vulnerabilities or replace technical judgment.

Organizations also confuse tool coverage with control effectiveness. A scanner deployed across all repositories may still be ineffective if findings are not triaged, thresholds are arbitrary, credentials are overprivileged or build logs can be altered. Conversely, a manual architectural review may be highly valuable for a small number of high-impact services even though it is not fully automated.

Metrics can create harmful incentives. Counting vulnerabilities may encourage teams to suppress findings; counting blocked builds may reward excessive strictness. More meaningful measures include time to remediate risk by severity and exposure, percentage of critical services with threat models, exception age, evidence completeness, mean time to revoke compromised credentials and the proportion of releases with traceable provenance.

Small teams face resource constraints, legacy systems may not support modern controls, and suppliers may provide incomplete evidence. Controls should therefore be prioritized according to risk, with compensating measures documented where ideal implementation is not yet feasible. Governance must remain demanding without becoming so burdensome that teams circumvent it.

There are also ethical concerns. Security policies can affect employee autonomy, developer evaluation and customer privacy. Monitoring pipeline activity should be limited to legitimate security and operational purposes, protected against misuse and communicated transparently. Automated decisions should allow meaningful review where false positives could delay essential services or unfairly affect individuals.

Automation, Analytics and Emerging Practice

Policy-as-code allows selected requirements to be expressed and evaluated automatically. Examples include rejecting infrastructure configurations that expose storage publicly, requiring approved base images, verifying artifact signatures or preventing deployment to production without a linked approval. Policy-as-code improves consistency, but policies require version control, testing, ownership and a documented change process.

Software supply-chain security is increasing the importance of provenance, artifact integrity, dependency transparency and build isolation. Organizations are adopting signed artifacts, attestations and software bills of materials to improve traceability. These mechanisms support investigation and assurance, but their value depends on trustworthy build environments and disciplined interpretation.

Analytics can help prioritize risk by combining vulnerability data with asset criticality, exploit intelligence, runtime exposure and remediation history. Machine-learning systems may assist triage, but they should not silently make high-impact risk-acceptance decisions. Human accountability remains necessary for ambiguous findings, business trade-offs and regulatory judgments.

Emerging governance practice is moving toward continuous control monitoring. Rather than preparing evidence only before an audit, organizations monitor whether controls remain configured and effective throughout the year. This approach can reduce audit friction and reveal drift earlier. It also creates a new responsibility: evidence collection must respect retention, privacy, access control and data-integrity requirements.

Best-Practice Principles

A defensible DevSecOps governance program should:

1. Begin with business objectives, risk scenarios and regulatory scope.

2. Use frameworks according to their purpose rather than treating them as identical checklists.

3. Define control objectives, owners, operators, thresholds and evidence requirements.

4. Automate repeatable controls while preserving human judgment for contextual decisions.

5. Make exceptions explicit, time-limited, compensating-control based and accountable.

6. Connect release, source, build, test and deployment records through traceable identifiers.

7. Measure residual risk, control effectiveness and exception aging rather than tool activity alone.

8. Review policies and controls after incidents, major architecture changes and recurring exceptions.

9. Protect audit evidence as sensitive information and restrict access appropriately.

10. Treat governance as a continuous improvement capability, not an annual compliance exercise.

Chapter Summary

Risk management, governance and compliance translate organizational priorities into accountable and testable DevSecOps practices. The translation begins with business objectives and risk scenarios, continues through requirements, policies and controls, and ends with evidence and authorized decisions. NIST CSF provides an enterprise cybersecurity outcome structure; NIST SSDF focuses on secure software practices; ISO/IEC 27001 supplies a risk-based information security management system; SOC 2 provides scoped assurance over trust-service controls; and OWASP SAMM supports software assurance maturity improvement.

Effective pipeline governance requires more than scanners and approval gates. It requires clear ownership, meaningful risk criteria, appropriate separation of duties, reliable evidence, controlled exceptions and explicit risk acceptance. Preventive, detective and corrective controls should work together across planning, source, build, testing, release and operations. Automation and policy-as-code improve consistency, but contextual human judgment remains essential. Mature organizations use metrics and continuous monitoring to improve control effectiveness while avoiding the false assurance that any framework or certification guarantees complete security.

Key Terms

Risk: The effect of uncertainty on organizational objectives.

Risk appetite: The amount and type of risk an organization is willing to pursue or retain.

Risk tolerance: The acceptable variation around a defined objective or risk threshold.

Inherent risk: Risk present before controls or treatments are applied.

Residual risk: Risk remaining after controls and treatments are applied.

Risk treatment: The process of avoiding, reducing, transferring or accepting risk.

Governance: Direction, oversight, accountability and decision-making authority.

Compliance: Adherence to applicable laws, regulations, contracts, standards and policies.

Assurance: Justified confidence that controls are suitably designed and operating effectively.

Control objective: The result a control is intended to achieve.

Control owner: The person accountable for a control’s design and operation.

Evidence: Information demonstrating control design, performance or effectiveness.

Exception: An authorized deviation from a policy or control requirement.

Risk acceptance: An authorized decision to retain a known risk under defined conditions.

NIST CSF: A framework for managing cybersecurity risk through organizational functions and outcomes.

NIST SSDF: A framework of practices for integrating security into software development.

ISO/IEC 27001: A standard specifying requirements for an information security management system.

SOC 2: An attestation approach evaluating controls against relevant Trust Services Criteria.

OWASP SAMM: A maturity model for assessing and improving software assurance capabilities.

Policy-as-code: Machine-readable policy rules that automatically evaluate technical configurations or delivery actions.

Review Questions

Short Answer Questions

1. Distinguish risk management, governance and compliance in a DevSecOps program.

2. What is the difference between inherent risk and residual risk?

3. Identify the four practice groups of NIST SSDF.

4. Why is evidence an essential part of control design?

5. What information should be included in an exception record?

Long Answer Questions

1. Explain how a business risk can be translated into a pipeline control using the business objective–risk–requirement–policy–control–evidence chain.

2. Compare the purposes and uses of NIST CSF, NIST SSDF, ISO/IEC 27001, SOC 2 and OWASP SAMM.

3. Discuss how accountability and separation of duties should be designed for software delivery governance.

4. Explain the role of preventive, detective and corrective controls across a DevSecOps pipeline.

5. Analyze the limitations of using compliance certification or automated scanning as evidence of complete security.

Analytical / Application Questions

1. A team requests an emergency production release with an unpatched high-severity dependency vulnerability. Design a risk-based exception and approval process, including compensating controls and evidence.

2. An organization has many automated security tools but cannot demonstrate which business risks they address. Propose a control-mapping and measurement approach.

3. A recurring stream of expired exceptions affects a critical service. Analyze possible organizational causes and recommend governance, technical and managerial interventions.

22. Multiple Choice Questions with Answers

Question 1

Which sequence best represents the translation of business risk into an auditable DevSecOps implementation?

A. Tool selection → dashboard → audit report → business objective

B. Business objective → risk scenario → policy → control → evidence → decision

C. Compliance certificate → scanner → exception → product launch

D. Incident → developer training → framework selection → risk appetite

Correct Answer: B. Business objective → risk scenario → policy → control → evidence → decision

Question 2

Which framework is most specifically focused on secure software development practices across preparation, production and vulnerability response?

A. NIST CSF

B. SOC 2

C. NIST SSDF

D. ISO/IEC 27001

Correct Answer: C. NIST SSDF

Question 3

A company wants a risk-based management system with continual improvement and documented treatment decisions. Which framework most directly addresses this need?

A. OWASP SAMM

B. ISO/IEC 27001

C. NIST SSDF

D. SOC 2

Correct Answer: B. ISO/IEC 27001

Question 4

Why should a scanner’s severity rating not automatically determine whether a release is blocked?

A. Scanners cannot identify any meaningful vulnerabilities

B. Severity must be interpreted with exposure, asset criticality and compensating controls

C. Blocking releases is never an appropriate security control

D. Regulatory frameworks prohibit automated decisions

Correct Answer: B. Severity must be interpreted with exposure, asset criticality and compensating controls

Question 5

Which item is least appropriate in a properly governed risk-acceptance record?

A. Defined expiry date

B. Compensating controls

C. Accountable approving authority

D. Permanent exemption without reassessment

Correct Answer: D. Permanent exemption without reassessment

Question 6

A SOC 2 Type II examination primarily provides evidence about:

A. The absence of all vulnerabilities in a product

B. The design and operating effectiveness of scoped controls over a period

C. Compliance with every international security law

D. The maturity of an organization’s threat-modeling program only

Correct Answer: B. The design and operating effectiveness of scoped controls over a period

Question 7

Which situation best demonstrates strong evidence architecture?

A. A dashboard displays a green status without underlying records

B. A deployment is linked to source, scan results, approvals, artifact and timestamp

C. A developer states that testing was completed

D. A policy exists but has no owner or operating record

Correct Answer: B. A deployment is linked to source, scan results, approvals, artifact and timestamp

Question 8

What is the principal purpose of OWASP SAMM in the context of this chapter?

A. To provide a software assurance maturity and improvement model

B. To issue an independent attestation report

C. To replace an enterprise risk-management system

D. To prescribe one mandatory pipeline toolchain

Correct Answer: A. To provide a software assurance maturity and improvement model

Question 9

A team repeatedly renews exceptions for the same control. What is the most appropriate governance interpretation?

A. The control is automatically effective because it is documented

B. The pattern may indicate impractical policy, insufficient resources or normalized unacceptable risk

C. All future exceptions should be approved automatically

D. The underlying risk no longer requires assessment

Correct Answer: B. The pattern may indicate impractical policy, insufficient resources or normalized unacceptable risk

Question 10

Which control arrangement most appropriately combines automation with accountable judgment?

A. Allow every developer to bypass failed controls without a record

B. Block all releases permanently whenever any scanner finding occurs

C. Permit a linked, time-limited, authorized exception with compensating controls and review

D. Remove security testing from emergency changes

Correct Answer: C. Permit a linked, time-limited, authorized exception with compensating controls and review