DevSecOps, Supply-Chain Security, and Ethics

Introduction

Continuous integration and continuous delivery (CI/CD) make software delivery faster and more repeatable, but automation also increases the speed at which defects, vulnerabilities, leaked credentials, and non-compliant components can reach users. DevSecOps integrates security into development and operations rather than treating it as a final approval stage. Its central principle is shared responsibility: developers, security specialists, platform engineers, and managers collectively protect code, pipelines, infrastructure, data, and users.

This chapter applies DevSecOps to Jenkins and GitHub Actions. It examines security testing, software supply-chain protection, least privilege, software bills of materials (SBOMs), signing, provenance, responsible access, privacy, and ethical decision-making.

Learning Objectives

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

• distinguish SAST, DAST, dependency, secret, license, IaC, and container scanning;
• place security controls at appropriate points in a CI/CD pipeline;
• apply least privilege and secure secret-management practices;
• explain SBOMs, artifact signing, provenance, and software supply-chain risk;
• design a basic security pipeline using Jenkins or GitHub Actions;
• evaluate privacy, authorization, fairness, and professional responsibility in DevSecOps;
• interpret security findings and make proportionate release decisions.

1. DevSecOps as a Delivery Model

Traditional delivery often places security after implementation. This creates late rework, encourages exceptions under schedule pressure, and may leave security knowledge concentrated in a specialist team. DevSecOps shifts security left by identifying problems early, while also shifting security right by monitoring deployed systems and responding to incidents.

A mature model contains three complementary practices:

1. Secure design: threat modelling, architectural review, data classification, and abuse-case analysis occur before implementation.
2. Automated assurance: tests and policy checks run repeatedly in pull requests, builds, deployments, and scheduled jobs.
3. Operational feedback: logs, vulnerability intelligence, runtime monitoring, and incident learning improve future changes.

“Shift left” does not mean that security is completed before deployment. Some risks, especially configuration drift and runtime attacks, can only be detected after deployment. Security must therefore be continuous.

A pipeline should be treated as a privileged production system. It can read source code, access package registries, build executable artifacts, and sometimes deploy to cloud environments. Compromise of a runner or pipeline identity may therefore compromise the entire software supply chain.

2. Security Scanning Across the Pipeline

No single scanner proves that software is secure. Each technique observes a different representation of the system and has characteristic false positives, false negatives, and operational costs.

2.1 Static Application Security Testing

SAST analyzes source code without executing the application. It can identify injection risks, unsafe deserialization, weak cryptography, path traversal, and insecure API use. SAST is most valuable when feedback is near the changed code and findings include a clear remediation explanation.

Teams should define severity thresholds and ownership. A critical finding in newly changed code may block a pull request, whereas a pre-existing medium finding may be recorded and assigned for later remediation. This distinction prevents “alert fatigue,” but exceptions must be time-limited, documented, and approved.

2.2 Dynamic Application Security Testing

DAST attacks a running application from an external perspective. It can identify authentication failures, missing security headers, exposed endpoints, and certain injection vulnerabilities. Test data must be synthetic or appropriately protected. DAST should run against an isolated environment; scanning production without authorization can cause service disruption or generate legally significant traffic.

Interactive application security testing (IAST) combines runtime instrumentation with test execution. It can provide more application context than DAST, but it introduces agent configuration and performance considerations.

2.3 Dependency and License Scanning

Modern applications depend on direct and transitive packages. Dependency scanning compares resolved versions with vulnerability advisories and may suggest upgrades. It should inspect lock files and the actual dependency graph rather than only manifest declarations.

License scanning identifies obligations associated with open-source components. A license is not merely a technical label: distribution, modification, attribution, source-availability, patent, and notice requirements may apply. Security and legal review should be connected, but a scanner should not be treated as a substitute for legal advice.

Useful controls include pinned versions, verified registries, lock files, dependency update automation, review of maintainer changes, and rapid response to critical advisories. Pinning improves reproducibility but does not itself guarantee that a package is safe.

2.4 Secret Scanning

Secrets include passwords, cloud access keys, private signing keys, database credentials, and API tokens. They must not be stored in source code, issue comments, build logs, container layers, or unencrypted configuration files.

Secret scanning should occur locally through developer hooks, in pull requests, and across repository history. If a secret is detected, deleting the line is insufficient: the credential must be revoked or rotated, exposure assessed, and historical copies removed where appropriate. Build logs should mask sensitive values, but masking is a defence-in-depth measure, not permission to print secrets.

2.5 Infrastructure-as-Code Scanning

IaC scanning checks cloud and orchestration definitions for risks such as public storage, unrestricted network access, excessive permissions, unencrypted databases, and missing audit logs. Findings should be interpreted in context. For example, a public endpoint may be intentional for a public web service but unacceptable for a database.

IaC should be reviewed like application code, tested in an isolated account or namespace, and applied using controlled identities. State files may contain sensitive values and therefore require encryption, access control, versioning, and careful retention.

2.6 Container Scanning

Container security includes the image build process, base image, installed packages, runtime configuration, and registry. Good practice includes minimal trusted base images, non-root execution, multi-stage builds, pinned image digests, removal of build tools from runtime images, and regular rebuilding.

Scanning should cover operating-system packages, language dependencies, image configuration, exposed ports, and embedded secrets. A “clean” scan is not proof of security: scanners have incomplete databases, and vulnerabilities can be introduced after the scan through runtime configuration or external services.

3. A Secure Jenkins or GitHub Actions Pipeline

A practical pipeline separates untrusted work from privileged work. Pull requests from forks should not automatically receive deployment credentials. Build jobs should use isolated, short-lived runners where possible. Privileged deployment jobs should require reviewed changes and, for production, an environment approval.

A representative sequence is:

1. validate formatting, tests, and policy files;
2. scan changed source for secrets;
3. run SAST and dependency checks;
4. build using a pinned toolchain;
5. scan IaC and the resulting container image;
6. generate an SBOM;
7. sign the artifact and record provenance;
8. deploy to an isolated environment;
9. run DAST and acceptance tests;
10. promote only according to documented risk thresholds.

In Jenkins, credentials should be stored in a managed credentials store and exposed only to the steps that require them. Pipeline libraries should be reviewed because shared libraries execute with pipeline authority. Jenkins controllers and agents must be patched, access-controlled, and separated from general-purpose workloads.

In GitHub Actions, use explicit action versions, preferably immutable commit references for sensitive actions. Set minimal job permissions, for example by declaring read-only contents access unless a job requires more. Protect environments, require reviews for production, restrict who can modify workflows, and consider the risks of self-hosted runners. A self-hosted runner can be dangerous if untrusted pull-request code executes on a machine containing persistent credentials or network access.

An illustrative GitHub Actions design is:

name: secure-build
on: [pull_request]
permissions:
  contents: read
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<reviewed-commit>
      - name: Run tests
        run: ./gradlew test
      - name: Scan dependencies and secrets
        run: ./ci/security-checks.sh
      - name: Build and scan image
        run: ./ci/build-scan.sh

The exact tools are less important than the control objectives: reproducibility, constrained permissions, traceable results, and separation between validation and deployment.

4. Supply-Chain Security

Software supply-chain security addresses risks introduced by people, tools, dependencies, build infrastructure, registries, and distribution channels. Examples include a compromised package maintainer account, malicious code in an update, a tampered build artifact, a poisoned container image, or a workflow modified to exfiltrate credentials.

4.1 SBOMs

An SBOM is a machine-readable inventory of software components and their relationships. It can include package names, versions, suppliers, licenses, hashes, and dependency relationships. Common formats include SPDX and CycloneDX.

SBOMs support vulnerability response, license review, asset inventory, and customer transparency. They are not a security certificate: an SBOM may accurately list a vulnerable component. It may also expose information that should be shared only with authorized recipients. SBOM generation should occur from the resolved build inputs, be stored with the artifact, and be updated when components change.

4.2 Signing and Provenance

Digital signatures provide evidence that a key approved a particular artifact or statement. Verification depends on protecting the signing key and establishing trust in the signer. Signing an insecure artifact does not make it secure; signing provides authenticity and integrity evidence.

Provenance records how an artifact was produced: source revision, builder, workflow, dependencies, parameters, and timestamps. Verifiable provenance helps consumers distinguish an artifact built by an authorized workflow from one uploaded directly by an attacker. SLSA is a widely discussed framework for improving build integrity and provenance, but adoption should be matched to organizational capability.

Keys should be held in hardware-backed or managed services where feasible, rotated according to policy, and separated by environment. Production signing should not be available to ordinary pull-request jobs.

4.3 Reproducibility and Trust

Reproducible builds aim for the same inputs to produce byte-equivalent outputs. This can reveal unauthorized build changes, although timestamps, compiler variation, nondeterministic ordering, and embedded environment information can make reproducibility difficult. Where byte reproducibility is not feasible, teams should record strong hashes, build metadata, and controlled toolchain versions.

Trust must be layered: verified source, reviewed workflow, isolated builder, controlled dependencies, signed output, and verified deployment. A single trusted badge is not an adequate security model.

5. Least Privilege and Secure Secrets

Least privilege means granting only the access necessary for a subject, for a limited period, to perform an identified task. Subjects include users, services, runners, actions, plugins, and deployment identities.

Practical controls include:

• separate identities for build, test, staging, and production;
• read-only permissions by default;
• short-lived, automatically issued credentials;
• workload identity or federated access instead of long-lived cloud keys;
• explicit permission declarations in workflows;
• network restrictions and isolated runners;
• approval gates for production;
• audit logs reviewed for unusual access.

Secrets should be injected at runtime from a secrets manager, not copied into repositories or baked into images. Access should be scoped to the job and environment. Rotation, revocation, backup, and incident procedures should be tested. Secret values should never be used as a mechanism for authorization decisions without additional identity and policy controls.

6. Ethics, Privacy, and Responsible Access

DevSecOps decisions affect employees, customers, communities, and public infrastructure. Ethical practice requires more than compliance with a checklist.

Responsible access means obtaining authorization before scanning, testing, reading, or modifying systems. Security researchers and students should define scope, avoid unnecessary data collection, minimize impact, document findings, and use coordinated disclosure. A vulnerability report should provide enough evidence to reproduce the issue without exposing personal data or enabling avoidable harm.

Privacy applies to pipeline logs, test databases, source code, SBOMs, telemetry, and security reports. Data minimization, purpose limitation, retention controls, access logging, and anonymization or synthetic data reduce risk. Production data should not be copied into development merely for convenience. Privacy obligations may arise from data-protection laws, contracts, sector regulations, and organizational policy.

Fairness and accountability matter when automated gates classify code, developers, or incidents. A scanner may produce more findings for teams using a particular language or legacy system. Managers should avoid using raw finding counts as simplistic performance measures. Teams need transparent criteria, appeal or review mechanisms, and support for remediation.

AI-assisted development introduces additional concerns: generated code may contain vulnerabilities, license ambiguity, fabricated dependencies, or accidental disclosure of proprietary prompts and source. AI output must undergo normal review, testing, scanning, and license assessment. It should not receive unrestricted repository or production access merely because it is embedded in a development tool.

7. Case Study: Northstar Payments (Illustrative)

Background

Northstar Payments operates a web service built by several teams. Its pipeline uses GitHub Actions, public package registries, and container deployment to a managed cloud platform.

Problem

A dependency update introduced a critical vulnerability. Investigation found that the pipeline used a long-lived cloud key, pull requests from forks ran on a self-hosted runner, images were unsigned, and no SBOM was retained. A secret had also appeared in an old build log.

Analysis

The immediate vulnerability was important, but the deeper issue was excessive trust. Untrusted code could run near credentials; consumers could not verify artifact origin; and the organization could not quickly determine which deployed services used the vulnerable package.

Approach

Northstar moved pull-request validation to isolated ephemeral runners, removed secrets from untrusted jobs, and replaced the cloud key with short-lived workload identity. It added dependency, secret, IaC, and container scanning; generated CycloneDX SBOMs; signed release images; and attached provenance to releases. Production deployment required a protected environment and two-person review. The exposed credential was revoked, logs were retained according to policy, and the affected package was upgraded.

Outcome

The organization could identify affected services from SBOMs, verify that production images came from the approved workflow, and reduce the impact of a compromised pull request. Some releases initially slowed because teams had to resolve findings and document exceptions. This was treated as a transition cost rather than a reason to remove controls.

Learning Points

Security controls are strongest when connected: scanning identifies risk, SBOMs support inventory, signing supports authenticity, provenance supports accountability, and least privilege limits blast radius. Governance must also address people, process, and data—not only tools.

8. Challenges and Limitations

Security tooling generates false positives, false negatives, duplicated findings, and inconsistent severity ratings. A pipeline that blocks every warning may be ignored or bypassed; one that blocks nothing provides little assurance. Teams should prioritize exploitability, exposure, business impact, affected assets, and remediation cost.

Security controls can also create build delays, maintenance work, and accessibility problems for small teams. Exceptions are sometimes legitimate, but they should include rationale, owner, compensating control, expiry date, and review. Metrics should emphasize meaningful outcomes: time to remediate critical findings, percentage of releases with verified provenance, credential exposure incidents, and coverage of important assets. Counting scans alone measures activity, not security.

No pipeline can guarantee absence of vulnerabilities. Secure delivery is a risk-management discipline supported by evidence, continuous improvement, and informed human judgment.

Best-Practice Checklist

• Define security ownership and release thresholds.
• Scan source, dependencies, secrets, IaC, and containers at suitable stages.
• Test deployed applications in authorized non-production environments.
• Use isolated runners and minimal, short-lived credentials.
• Pin and review actions, dependencies, tools, and base images.
• Generate and protect SBOMs.
• Sign artifacts and verify signatures before deployment.
• Record build provenance and retain audit evidence.
• Protect production environments with approvals and separation of duties.
• Use synthetic or minimized data in testing.
• Document exceptions and review them before expiry.
• Train teams in ethical testing, privacy, and responsible disclosure.

Chapter Summary

DevSecOps integrates security throughout software delivery. SAST, DAST, dependency, secret, license, IaC, and container scanning address different evidence sources and must be interpreted together. CI/CD systems are privileged infrastructure and require isolated runners, explicit permissions, protected environments, and short-lived credentials. SBOMs improve component visibility; signing provides integrity and signer evidence; provenance records how an artifact was built. These controls are effective only when keys, identities, workflows, and registries are protected. Ethical DevSecOps also requires authorized testing, privacy protection, fair interpretation of automated findings, responsible disclosure, and accountability for AI-assisted development. The goal is not a perfect scan result but a demonstrably controlled, explainable, and continuously improving delivery process.

Key Terms

DevSecOps: An approach integrating security into development, delivery, and operations.

SAST: Static analysis of source code or bytecode for security defects.

DAST: Dynamic testing of a running application.

Dependency scanning: Analysis of direct and transitive software components for known risks.

Secret scanning: Detection of credentials and sensitive tokens in code and artifacts.

License scanning: Identification of software-license obligations and conflicts.

IaC scanning: Security analysis of infrastructure-as-code definitions.

Container scanning: Examination of container images, packages, and configuration.

SBOM: A machine-readable inventory of software components and relationships.

Provenance: Evidence describing an artifact’s source, builder, inputs, and process.

Artifact signing: Cryptographic approval of a specific software object or statement.

Least privilege: Granting only necessary access for a limited purpose and duration.

Workload identity: A mechanism allowing a workload to obtain scoped credentials without storing long-lived keys.

Runner: The machine or environment that executes CI/CD jobs.

Reproducible build: A build designed to produce equivalent output from equivalent inputs.

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

Coordinated disclosure: Reporting vulnerabilities to affected parties in a controlled manner.

Exception: A documented, approved deviation from a security policy.

Review Questions

Short Answer Questions

1. What is the principal difference between SAST and DAST?
2. Why is an SBOM useful during vulnerability response?
3. State two risks associated with self-hosted CI runners.
4. What does least privilege mean in a CI/CD pipeline?
5. Why does signing an artifact not prove that the artifact is secure?

Long Answer Questions

1. Explain how dependency, secret, license, IaC, and container scanning complement one another.
2. Design a secure promotion path from pull request to production using Jenkins or GitHub Actions.
3. Discuss the relationship between SBOMs, signing, provenance, and supply-chain trust.
4. Explain how privacy and responsible access should influence security testing.
5. Evaluate the benefits and limitations of shifting security left.

Analytical / Application Questions

1. A pull request from an external contributor needs to run tests, but the repository contains deployment credentials. Design a safe job structure and justify each control.
2. A scanner reports a critical vulnerability in a package that is present but unreachable in the deployed service. What evidence and governance process should determine whether release is blocked?
3. An organization has signed images but cannot identify which services use a vulnerable dependency. Identify the missing control and propose a practical improvement plan.

Multiple Choice Questions with Answers

Question 1

Which technique analyzes an application while it is running?

A. SAST

B. DAST

C. License scanning

D. SBOM generation

Correct Answer: B. DAST

Question 2

What is the primary purpose of an SBOM?

A. To encrypt source code

B. To replace vulnerability testing

C. To inventory software components and relationships

D. To authorize production deployment

Correct Answer: C. To inventory software components and relationships

Question 3

Which practice best protects a deployment credential in a CI/CD system?

A. Commit it to a private repository

B. Print it only in successful logs

C. Store it in an image layer

D. Use short-lived, scoped runtime credentials

Correct Answer: D. Use short-lived, scoped runtime credentials

Question 4

Why should pull requests from untrusted forks generally avoid production secrets?

A. They may execute code controlled by an external contributor

B. They cannot contain source code

C. They always fail automated tests

D. They cannot access public dependencies

Correct Answer: A. They may execute code controlled by an external contributor

Question 5

What does artifact signing primarily provide?

A. Proof that the code has no vulnerabilities

B. Evidence of integrity and approval by a signing identity

C. Automatic license compliance

D. Guaranteed reproducible builds

Correct Answer: B. Evidence of integrity and approval by a signing identity

Question 6

Which control examines Terraform or Kubernetes configuration for insecure settings?

A. IaC scanning

B. DAST

C. Secret rotation

D. Load testing

Correct Answer: A. IaC scanning

Question 7

What should normally happen after a secret is found in repository history?

A. Only delete the visible line

B. Ignore it if the repository is private

C. Revoke or rotate the credential and assess exposure

D. Rename the variable

Correct Answer: C. Revoke or rotate the credential and assess exposure

Question 8

Which statement about a security exception is best practice?

A. It should be permanent once approved

B. It should include an owner, rationale, compensating control, and expiry

C. It should be hidden to avoid audit concerns

D. It removes the need for remediation

Correct Answer: B. It should include an owner, rationale, compensating control, and expiry

Question 9

What does provenance describe?

A. The popularity of a software package

B. The number of users of an application

C. How an artifact was produced and from which inputs

D. The legal owner of a cloud account

Correct Answer: C. How an artifact was produced and from which inputs

Question 10

Why should production deployment environments be protected by approval controls?

A. To prevent all automated deployment

B. To separate validation from high-impact release authority

C. To make source code unavailable to developers

D. To eliminate the need for testing

Correct Answer: B. To separate validation from high-impact release authority