1. DevSecOps Foundations, Culture and Terminology

Introduction and Context

DevOps emerged as a response to the separation between software development and IT operations. Traditionally, developers were evaluated on how quickly they delivered new functionality, while operations teams were evaluated on system stability and availability. Security teams often worked as a final approval function, reviewing applications late in the delivery cycle. This arrangement created queues, conflict, delayed releases, and a tendency to treat security as an obstacle rather than as a shared engineering responsibility.

DevSecOps extends the DevOps philosophy by integrating security into the culture, processes, and technical systems used to design, build, release, operate, and retire software. It is not simply the addition of security tools to a continuous integration and continuous delivery pipeline. It is an operating model in which security is considered continuously, evidence is produced through automation, risks are addressed by the people closest to the work, and accountability remains shared across the organization.

The importance of this foundation is practical as well as conceptual. Modern organizations depend on software supply chains, cloud platforms, APIs, infrastructure as code, containers, mobile applications, and automated deployment systems. A weakness in any of these elements may expose customers, employees, data, or critical services. DevSecOps therefore connects software delivery performance with security assurance, resilience, governance, and business risk management.

Learning Objectives

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

1. Explain the relationship between DevOps, cybersecurity, and DevSecOps.

2. Distinguish shift-left, shift-right, and continuous assurance approaches.

3. Describe the shared-responsibility culture required for secure delivery.

4. Apply Zero Trust principles to software delivery and operations.

5. Explain security debt and analyze its organizational consequences.

6. Use the people-process-technology model to evaluate DevSecOps capability.

7. Identify relevant terminology, risks, governance considerations, and professional practices.

8. Analyze an organizational scenario and recommend an appropriate DevSecOps response.

From DevOps to DevSecOps

DevOps is a sociotechnical approach that combines practices, cultural values, and automation to improve the flow of value from an idea to a reliable running service. Its commonly recognized goals include shorter delivery cycles, improved collaboration, dependable operations, rapid feedback, and continual improvement. Continuous integration, continuous delivery, infrastructure as code, observability, automated testing, and site reliability practices are examples of DevOps techniques.

Cybersecurity, by contrast, protects the confidentiality, integrity, and availability of information and systems. Contemporary security also includes authenticity, accountability, privacy, resilience, and the ability to detect and recover from misuse. Security engineering addresses vulnerabilities and threats, while governance establishes acceptable risk, roles, controls, and evidence of compliance.

DevSecOps joins these concerns. A DevSecOps pipeline seeks to make secure behavior part of ordinary delivery work. Security requirements are identified when a product is conceived; designs are reviewed before implementation; source code, dependencies, infrastructure definitions, and deployment configurations are tested automatically; runtime behavior is monitored; and lessons from incidents are fed back into development. The objective is not to eliminate all risk, which is generally impossible, but to make risk visible, measurable, prioritized, and manageable.

A useful distinction is between security as a separate gate and security as a continuous capability. A gate may stop a release when a rule is violated, but a mature capability helps teams prevent defects, understand exceptions, select proportionate controls, and improve over time. DevSecOps does not remove specialist security expertise. Instead, security specialists act as enablers, architects, educators, investigators, and risk advisers while development and operations teams assume responsibility for security in their own work.

Culture: From Handoffs to Shared Responsibility

The cultural foundation of DevSecOps is shared responsibility. This does not mean that every person performs every security task. It means that security outcomes are not assigned exclusively to a security department. Product owners, architects, developers, testers, platform engineers, operations staff, security professionals, compliance officers, and senior managers each contribute to the protection of the service.

Shared responsibility requires clarity. Organizations should define who owns a service, who approves risk exceptions, who maintains security controls, who responds to incidents, and who verifies that controls are effective. Ambiguous responsibility creates a predictable failure pattern: each group assumes that another group has addressed the risk.

A healthy culture also depends on psychological safety. If engineers are punished for reporting vulnerabilities or configuration mistakes, problems will be hidden until they become incidents. Blameless post-incident reviews do not mean that negligence or misconduct is ignored. They mean that investigations first examine systems, incentives, tooling, workload, communication, and decision-making rather than searching immediately for an individual to blame. Where intentional misconduct or reckless behavior exists, formal accountability remains necessary.

Security culture is reinforced by incentives. If delivery speed is rewarded while secure design is invisible, teams will optimize for speed. Balanced measures may include deployment frequency, lead time, change failure rate, recovery time, vulnerability remediation time, policy exception age, coverage of automated controls, and the proportion of critical assets with clear ownership. Metrics should support learning rather than encourage teams to conceal problems.

The Security Lifecycle: Shift Left, Shift Right, and Continuous Assurance

Shift-left security

Shift-left means addressing security earlier in the software lifecycle, when changes are easier and less expensive to modify. Examples include threat modeling during design, secure coding education, dependency selection, secret detection in source repositories, and automated static analysis during continuous integration.

Shift-left is valuable because a design flaw can affect architecture, data flows, and authorization assumptions across the whole system. Detecting it after deployment may require emergency changes, customer communication, data analysis, and regulatory reporting. However, shift-left should not be interpreted as shifting all security responsibility onto developers. Early activities must be supported by usable tools, training, security patterns, and specialist consultation.

Shift-right security

Shift-right extends security into staging, production, and post-release operation. It includes runtime application protection, identity monitoring, vulnerability management, cloud configuration assessment, log analysis, detection engineering, incident response, backup validation, penetration testing, and recovery exercises. Some threats can only be understood in the operational environment because real traffic, integrations, permissions, and attacker behavior are not fully represented before release.

Shift-right also recognizes that security is an operational property. A secure application may become exposed through a misconfigured storage service, an overprivileged identity, an unpatched host, or a compromised third-party integration. Runtime visibility and response capability are therefore essential.

Continuous assurance

Continuous assurance is the combination of preventive, detective, and corrective activities that provide ongoing confidence that security requirements remain effective. It differs from a one-time audit. A control that was effective during an assessment may fail after a configuration change, new dependency, altered permission, or deployment to another environment.

A continuous assurance loop can be described as follows:

• define security and compliance requirements;
• translate requirements into testable policies and controls;
• collect evidence through pipelines, platforms, and operational systems;
• evaluate findings according to likelihood, impact, exposure, and exploitability;
• remediate, mitigate, transfer, or formally accept risk;
• monitor whether the decision remains valid; and
• improve requirements and controls using incidents and lessons learned.

This approach treats evidence as a by-product of engineering rather than as an emergency activity performed before an audit. Nevertheless, automated evidence does not guarantee effective security. Organizations must validate that controls address real risks and that teams are not merely optimizing for passing scans.

Zero Trust as a DevSecOps Principle

Zero Trust is a security approach based on the assumption that trust should not be granted merely because a user, workload, or device is inside a network boundary. Access decisions should be explicit, contextual, least-privileged, and continuously evaluated where practical. Common principles include verifying identity, limiting access, segmenting resources, protecting communications, observing activity, and assuming that compromise is possible.

Zero Trust is particularly relevant to DevSecOps because delivery pipelines themselves are high-value systems. A pipeline may access source code, signing keys, cloud accounts, package repositories, production environments, and customer data. If its credentials are stolen, an attacker may insert malicious code or alter infrastructure. Applying Zero Trust to the pipeline involves strong identity for people and workloads, short-lived credentials, separation of duties for sensitive actions, protected branches, authenticated artifacts, environment-specific authorization, and detailed audit records.

Zero Trust is not equivalent to denying all access or repeatedly requesting passwords. It is a risk-based architectural and governance approach. For example, a deployment request may be permitted only when it comes from an approved workload identity, references an authenticated artifact, has passed required tests, targets an authorized environment, and satisfies change policy. The decision may also consider the sensitivity of the service and the context of the request.

Security Debt and the Cost of Deferred Protection

Technical debt describes future cost created when a short-term implementation choice makes later change more difficult. Security debt is the accumulated exposure, remediation effort, and uncertainty created when security weaknesses, missing controls, unsupported components, undocumented exceptions, or poor architectural decisions are deferred.

Examples include an unmaintained library, hard-coded credentials, excessive privileges, absent audit logging, weak secrets management, an untested recovery plan, or a legacy service that cannot support modern authentication. Security debt is dangerous because it compounds. A vulnerable component may be copied into multiple services; an undocumented exception may become a permanent dependency; and a missing control may make later assurance expensive.

Security debt should be managed as a portfolio rather than as a list of scanner findings. Teams should consider exploitability, business impact, exposure, asset criticality, compensating controls, remediation effort, and the likelihood that the weakness will spread. Prioritization may favor a moderate vulnerability in an internet-facing identity service over a severe vulnerability in an isolated test system.

Debt management also requires visibility. Organizations can record the owner, affected asset, risk rationale, due date, temporary mitigation, and acceptance authority for each significant item. A risk acceptance document is not remediation; it is a time-bounded decision to tolerate exposure under specified conditions.

The People–Process–Technology Operating Model

DevSecOps capability can be analyzed through three interdependent dimensions.

People

People include technical practitioners, managers, executives, security specialists, auditors, suppliers, and users. Important capabilities include secure design, threat analysis, incident response, cloud and identity engineering, communication, and risk judgment. Education should be role-specific: a developer may need guidance on input validation and dependency management, while a product manager may need to understand data classification and risk prioritization.

Leadership establishes expectations and allocates resources. Security champions embedded in product teams can improve communication, but they should not become unpaid substitutes for a security function. Teams also need manageable workloads; excessive alert volume and constant emergency work produce fatigue and encourage unsafe shortcuts.

Process

Processes convert intentions into repeatable behavior. Relevant processes include security requirements, architecture review, threat modeling, vulnerability triage, code review, release approval, access management, incident response, exception handling, supplier assessment, and post-incident learning. Mature processes are proportionate and integrated with existing work rather than being parallel bureaucracy.

A process should have an owner, a trigger, defined inputs and outputs, decision criteria, escalation paths, and evidence requirements. For instance, a vulnerability process should specify severity assessment, service-level expectations, temporary mitigations, verification of fixes, and closure conditions.

Technology

Technology provides automation, visibility, and enforcement. Examples include source-control protections, secret scanning, software composition analysis, static and dynamic application testing, infrastructure-as-code scanning, container and image assessment, identity and access management, policy-as-code, artifact signing, security information and event management, endpoint protection, and observability platforms.

Tools are not self-implementing controls. A scanner may produce false positives, miss business-logic flaws, or identify a problem that no team is authorized to fix. Tool selection should therefore consider accuracy, integration, developer experience, coverage, ownership, data protection, and the ability to prioritize findings. A small number of well-integrated controls is often more effective than a large collection of disconnected tools.

The three dimensions reinforce one another. Skilled people using weak processes may act inconsistently; excellent processes without usable technology may become manual bottlenecks; and advanced tools without responsible ownership may generate ignored alerts. DevSecOps maturity is consequently a systems property rather than a procurement outcome.

Terminology for Professional Practice

Several terms are used throughout DevSecOps. A vulnerability is a weakness that can be exploited. A threat is a potential cause of harm, while risk combines the likelihood and impact of an unwanted event. An exploit is a technique or code that takes advantage of a vulnerability. An exposure is the condition of being accessible or subject to a threat, and a control is a safeguard intended to prevent, detect, deter, or correct an adverse event.

A software bill of materials (SBOM) is a structured inventory of components used to build software. It supports dependency visibility and vulnerability response, but it does not by itself prove that software is secure. An artifact is a packaged output of a build, such as a container image or binary. Artifact provenance records information about how, where, and from which inputs an artifact was produced. Attestation is a verifiable statement about an artifact or process, such as the result of a build or test.

Threat modeling is a structured examination of assets, trust boundaries, attack paths, abuse cases, and mitigations. Static application security testing examines source or compiled code without executing the application; dynamic testing examines a running application; and software composition analysis evaluates third-party and open-source dependencies. These techniques are complementary rather than interchangeable.

An incident is a security event that requires investigation or response. A security event is any observable occurrence relevant to security, although not every event is an incident. Mean time to detect and mean time to recover are operational measures, but they should be interpreted alongside impact, recurrence, and quality of response.

Applying DevSecOps in an Organization

Implementation should begin with an assessment of business services, data, delivery pathways, existing controls, skills, and risk appetite. Organizations should identify a small number of critical services and map their development and operational lifecycle. This reveals where requirements are lost, where credentials are shared, where approvals are manual, and where monitoring is absent.

A practical progression often includes the following activities:

1. Establish ownership for products, pipelines, environments, identities, and data.

2. Define baseline security requirements according to service criticality.

3. Protect source repositories and pipeline identities.

4. Introduce automated checks at appropriate points in the delivery workflow.

5. Establish vulnerability triage, exception, and remediation practices.

6. Improve runtime logging, detection, response, backup, and recovery.

7. Measure outcomes and use feedback to refine controls.

Controls should be risk-based. A low-risk internal prototype may require different assurance from a payment service or a system processing sensitive health information. Risk-based does not mean informal: the rationale for differing requirements should be documented and approved.

Illustrative Case Study: MeridianPay’s Release Pipeline

Background

MeridianPay is a fictional mid-sized payment technology provider operating several customer-facing services in a public cloud. Development teams release frequently, but security review occurs only before major releases. The organization has a central security team of six specialists and approximately 90 engineers distributed across product teams.

Situation and Problem

A routine review discovers that one service uses an outdated open-source component with a publicly documented vulnerability. The component is present in several repositories. The security team also finds long-lived cloud credentials in two pipeline configurations, inconsistent logging between environments, and no formal process for recording risk acceptance. Product teams argue that the vulnerability scanner produces too many findings and that security review delays releases.

Analysis

The problem is not only the vulnerable component. It reflects weak ownership, late security involvement, poor dependency visibility, excessive credential privilege, and an absence of a common risk decision process. The organization has some technology but lacks the people and processes required to use it effectively. Its approach is predominantly a late-stage gate rather than continuous assurance.

Approach and Solution

MeridianPay first identifies the payment service owner and maps where the component is used. It generates an SBOM for relevant artifacts and prioritizes the exposed production services rather than treating every finding as equally urgent. Temporary network restrictions and enhanced monitoring reduce exposure while teams update or replace the component.

The company replaces long-lived pipeline credentials with workload identities and short-lived tokens. Protected branches, mandatory peer review, and signed build artifacts are introduced for production-bound releases. Secret scanning runs on commits and repository history, while dependency checks run during builds. A lightweight threat-modeling workshop is required for material architectural changes.

A vulnerability policy defines severity, exploitability, asset criticality, remediation targets, compensating controls, and approval authority for exceptions. Security champions in each product team receive training and meet regularly with the central security group. Runtime logging and alert ownership are standardized, and an incident exercise tests whether teams can revoke credentials and restore a known-good deployment.

Outcome

The immediate vulnerability is remediated or mitigated according to service exposure. More importantly, MeridianPay gains visibility into component use, reduces the privilege of its pipelines, and moves security decisions closer to engineering work. The central security team spends less time manually reviewing routine changes and more time on architecture, threat intelligence, and complex investigations.

Learning Points

The case demonstrates that DevSecOps is not achieved by purchasing a scanner. It requires service ownership, risk-based prioritization, identity controls, evidence, operational monitoring, and collaboration. It also shows why shift-left and shift-right must operate together: early testing reduces preventable defects, while runtime capability limits the consequences of defects that escape into production.

Challenges, Limitations, and Common Mistakes

DevSecOps programs commonly fail when organizations treat security as a compliance checklist, deploy tools without assigning owners, or measure the number of findings instead of reduction in meaningful risk. Excessive blocking controls can encourage bypasses, while weak controls can create a false sense of assurance. Automation may also encode flawed assumptions and reproduce them at scale.

Other challenges include legacy systems, fragmented ownership, supplier dependencies, limited security expertise, alert fatigue, conflicting delivery incentives, and uncertainty about acceptable risk. Cloud environments can make change rapid but responsibility less visible. Regulatory requirements may mandate evidence and controls, but compliance does not guarantee resistance to attack.

Organizations should avoid claiming that a pipeline is secure merely because it passes tests. Automated tests have coverage limits, threat models can become outdated, and attackers can exploit business processes that technical scanners do not understand. Human review, adversarial testing, operational monitoring, and independent assurance remain important.

Governance, Ethics, and Professional Responsibility

DevSecOps decisions affect privacy, safety, access to essential services, and the security of third parties. Teams should collect only necessary data, protect logs and test data, control access to security findings, and avoid using production personal information in development environments without appropriate safeguards. Security testing must be authorized, bounded, and documented.

Governance should define risk appetite, control ownership, evidence retention, incident reporting, supplier expectations, and escalation paths. Legal and regulatory obligations vary by jurisdiction and industry, so organizations must interpret them with qualified professional advice. Ethical practice goes beyond minimum compliance: engineers should consider foreseeable misuse, vulnerable users, discriminatory outcomes from automated decisions, and the consequences of concealing known weaknesses.

Emerging Directions

DevSecOps is increasingly influenced by software supply-chain security, identity-centric architecture, policy-as-code, confidential computing, automated provenance, and machine-assisted analysis. Artificial intelligence can help summarize findings, generate tests, identify anomalous activity, and assist with secure coding. However, AI-generated code may contain vulnerabilities, expose sensitive information through inappropriate prompts, or introduce uncertain dependencies. Human review, controlled data handling, testing, and accountability remain essential.

The emerging direction is toward evidence-rich, identity-aware, continuously evaluated delivery systems. Organizations will increasingly seek verifiable information about who built an artifact, what inputs were used, which tests ran, what policies were satisfied, and where the artifact was deployed. This development strengthens assurance but does not replace engineering judgment or resilience planning.

Best Practices for a Foundational DevSecOps Program

A sound foundation generally includes the following practices:

• assign explicit ownership for services, data, environments, and pipelines;
• involve security in design without making specialists the sole owners of security;
• use threat modeling for material architectural and data-flow changes;
• protect identities, secrets, source repositories, and build infrastructure;
• automate proportionate tests and make results actionable;
• maintain dependency and artifact visibility, including provenance where feasible;
• monitor production behavior and rehearse incident response and recovery;
• prioritize vulnerabilities by real risk rather than severity labels alone;
• document time-bounded exceptions and verify compensating controls; and
• use blameless learning, meaningful metrics, and continuous improvement.

Chapter Summary

DevSecOps integrates security with the culture, processes, and automation of DevOps. Its central idea is shared responsibility: security is a collective outcome supported by specialist expertise, not a final-stage task owned only by a security department. Shift-left practices address risks early in design and development, while shift-right practices provide runtime detection, response, and recovery. Continuous assurance connects requirements, automated evidence, risk decisions, and feedback throughout the lifecycle.

Zero Trust strengthens DevSecOps by requiring explicit, least-privileged, context-aware access for users and workloads, including delivery pipelines. Security debt represents the accumulated exposure and future cost created by deferred controls and weaknesses. The people-process-technology model explains why tools alone cannot create security capability. Effective programs combine skilled and accountable people, proportionate repeatable processes, and integrated technology. Governance, ethics, privacy, resilience, and professional judgment remain necessary because no automated pipeline can eliminate uncertainty or risk.

Key Terms

DevOps: A sociotechnical approach that integrates development and operations to improve software delivery and service reliability.

DevSecOps: An operating model that embeds security throughout software development, delivery, and operations.

Shared responsibility: The principle that security outcomes are distributed among relevant roles rather than assigned only to security specialists.

Shift-left security: Addressing security requirements and weaknesses early in design and development.

Shift-right security: Extending security detection, response, and assurance into staging and production operations.

Continuous assurance: Ongoing evaluation and improvement of security controls using requirements, evidence, monitoring, and feedback.

Zero Trust: A security approach that requires explicit, least-privileged, and context-aware access decisions instead of implicit network trust.

Security debt: Accumulated exposure, uncertainty, and future remediation cost caused by deferred security work.

Threat: A potential cause of harm to a system, organization, or stakeholder.

Vulnerability: A weakness that can be exploited or otherwise lead to an undesirable security outcome.

Risk: The combination of the likelihood and impact of a harmful event.

Control: A safeguard intended to prevent, detect, deter, or correct an adverse event.

Threat modeling: A structured analysis of assets, trust boundaries, threats, attack paths, and mitigations.

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

Artifact provenance: Evidence describing how, where, and from which inputs a software artifact was produced.

Static application security testing: Examination of source or compiled code without executing the application.

Dynamic application security testing: Security testing performed against a running application.

Policy as code: Expressing organizational or security rules in machine-readable form so they can be tested or enforced automatically.

Risk acceptance: A documented, authorized decision to tolerate specified exposure under defined conditions.

Security champion: A team member who promotes security practices and communication within a product or engineering team.

Review Questions

Short Answer Questions

1. What distinguishes DevSecOps from adding a security gate at the end of a delivery pipeline?

2. Define shift-left security and provide two examples.

3. Why is shared responsibility important in DevSecOps?

4. What is security debt? Give two examples.

5. State two Zero Trust principles relevant to a CI/CD pipeline.

Long Answer Questions

1. Explain how DevOps, cybersecurity, and DevSecOps are related. Discuss the organizational changes required to integrate them.

2. Compare shift-left, shift-right, and continuous assurance. Explain why a mature program requires all three.

3. Discuss the people-process-technology operating model and show why weakness in one dimension can undermine the others.

4. Explain how Zero Trust can be applied to identities, artifacts, and deployment decisions in a software pipeline.

5. Analyze the governance, ethical, and professional responsibilities involved in managing security exceptions and vulnerabilities.

Analytical / Application Questions

1. A team has excellent static scanning but no production monitoring, incident exercise, or recovery testing. Use the chapter’s concepts to evaluate its DevSecOps maturity and recommend improvements.

2. An organization has hundreds of high-severity dependency findings but only three internet-facing services. Design a risk-based prioritization approach and identify the evidence required for decisions.

3. A developer reports that a pipeline uses a shared administrator credential and that removing it may delay releases. Formulate a response using shared responsibility, Zero Trust, security debt, and continuous assurance principles.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes DevSecOps?

A. A security approval performed only after development is complete

B. An operating model that integrates security throughout delivery and operations

C. A replacement for all specialist cybersecurity roles

D. A compliance process limited to documenting controls

Correct Answer: B. An operating model that integrates security throughout delivery and operations

Question 2

A team performs threat modeling during architecture design and scans dependencies during builds. These practices primarily demonstrate which approach?

A. Shift-left security

B. Shift-right security

C. Risk acceptance

D. Incident containment

Correct Answer: A. Shift-left security

Question 3

Why is shift-right security necessary even when strong pre-release testing exists?

A. Production environments never require access controls

B. Runtime configuration, real traffic, and attacker behavior may reveal additional risks

C. It eliminates the need for secure coding

D. It guarantees that no vulnerability reaches production

Correct Answer: B. Runtime configuration, real traffic, and attacker behavior may reveal additional risks

Question 4

Which action most closely reflects Zero Trust applied to a deployment pipeline?

A. Allowing any user inside the corporate network to deploy

B. Using one permanent administrator credential for all environments

C. Requiring explicit authorization and least privilege for a workload identity

D. Disabling audit logs to improve pipeline speed

Correct Answer: C. Requiring explicit authorization and least privilege for a workload identity

Question 5

Which situation is the clearest example of security debt?

A. A documented and tested security control

B. A temporary, approved exception with an expiry date

C. An unsupported library retained without ownership or remediation planning

D. A completed incident recovery exercise

Correct Answer: C. An unsupported library retained without ownership or remediation planning

Question 6

A vulnerability scanner reports 500 findings, but only ten affect internet-facing critical services. What should the organization do first?

A. Treat every finding as equally urgent

B. Delete the scanner results

C. Prioritize using exposure, asset criticality, exploitability, and impact

D. Accept all findings automatically

Correct Answer: C. Prioritize using exposure, asset criticality, exploitability, and impact

Question 7

Which example best illustrates continuous assurance?

A. Conducting one security audit before the first release

B. Collecting control evidence continuously and reassessing risk after changes

C. Blocking every deployment regardless of risk

D. Delegating all security decisions to an external auditor

Correct Answer: B. Collecting control evidence continuously and reassessing risk after changes

Question 8

Why can tools alone fail to establish DevSecOps capability?

A. Tools cannot produce any security information

B. Tools require ownership, usable processes, interpretation, and remediation decisions

C. Automation is incompatible with secure delivery

D. Security tools are useful only in production

Correct Answer: B. Tools require ownership, usable processes, interpretation, and remediation decisions

Question 9

Which response best reflects a healthy shared-responsibility culture after a security incident?

A. Punish the first individual associated with the change

B. Suppress the incident to protect delivery metrics

C. Investigate system conditions and decisions while retaining accountability for misconduct

D. Transfer all future security work to the security department

Correct Answer: C. Investigate system conditions and decisions while retaining accountability for misconduct

Question 10

MeridianPay replaces long-lived pipeline credentials with short-lived workload identities. What primary principle does this support?

A. Least privilege and Zero Trust

B. Security through obscurity

C. Elimination of software dependencies

D. Removal of runtime monitoring

Correct Answer: A. Least privilege and Zero Trust