Security & DevSecOps Glossary for Auditors
This glossary explains key technical terms in plain language, tailored for auditors, compliance officers, and risk managers. For each term, we explain what it is, why auditors care, and what evidence to look for.
CI/CD (Continuous Integration / Continuous Delivery)
What it is: An automated system that builds, tests, and deploys software every time developers make changes. Think of it as a digital assembly line for software — code goes in one end, tested and packaged software comes out the other.
Why auditors care: CI/CD pipelines are the control enforcement layer for software delivery. If security controls are not embedded in this pipeline, they are likely not enforced at all. Under DORA and NIS2, CI/CD systems qualify as regulated ICT systems.
Evidence to look for: Pipeline execution logs with timestamps, mandatory stage completion records, approval workflows before production deployment.
Pipeline
What it is: A sequence of automated steps (build, test, scan, deploy) that code must pass through before reaching production. Each step can enforce a security gate.
Why auditors care: The pipeline architecture determines whether security controls are mandatory or optional. A well-designed pipeline prevents unapproved code from reaching production.
Evidence to look for: Pipeline configuration files showing mandatory stages, gate pass/fail logs, records of blocked deployments.
SAST (Static Application Security Testing)
What it is: Automated analysis of source code to find security vulnerabilities before the software runs. It reads the code like a reviewer would, looking for known vulnerability patterns.
Why auditors care: SAST provides evidence that security testing happens early in development. It demonstrates the organization proactively identifies vulnerabilities rather than discovering them in production.
Evidence to look for: Scan logs with timestamps, policy enforcement showing builds blocked on critical findings, trend reports showing remediation rates over time, documented suppression/exception processes.
DAST (Dynamic Application Security Testing)
What it is: Automated testing of a running application by simulating real attacks. Unlike SAST (which reads code), DAST tests the application as an attacker would — from the outside.
Why auditors care: DAST validates that deployed applications are resilient against known attack patterns. It complements SAST by testing real-world behaviour, not just code.
Evidence to look for: DAST scan reports with identified vulnerabilities and severity ratings, remediation timelines, recurring scan schedules, integration with CI/CD pipeline logs.
SCA (Software Composition Analysis)
What it is: Automated scanning of third-party libraries and dependencies used in software. Most modern applications are 70-90% third-party code — SCA checks whether that code has known vulnerabilities or licence risks.
Why auditors care: Third-party component risk is a key concern under DORA Article 28 and NIS2 supply chain requirements. SCA provides visibility into the software supply chain.
Evidence to look for: Dependency inventories, vulnerability reports for third-party components, licence compliance checks, automated blocking of components with critical vulnerabilities.
SBOM (Software Bill of Materials)
What it is: A complete, machine-readable inventory of every component (libraries, frameworks, dependencies) included in a software application. Think of it as a nutrition label for software.
Why auditors care: SBOMs are increasingly mandated by regulation. They enable traceability of supply chain components and rapid impact assessment when new vulnerabilities are disclosed.
Evidence to look for: Generated SBOM files (SPDX or CycloneDX format), automated SBOM generation in CI/CD pipelines, SBOM retention and versioning records.
IAST (Interactive Application Security Testing)
What it is: A hybrid testing approach that monitors applications from the inside during testing. An agent is embedded in the application and observes real code execution paths to identify vulnerabilities with high accuracy.
Why auditors care: IAST provides highly accurate results with fewer false positives than SAST or DAST alone, which means findings are more actionable and auditable.
Evidence to look for: IAST agent deployment records, test execution reports, vulnerability findings correlated with specific code paths.
RASP (Runtime Application Self-Protection)
What it is: A runtime security agent embedded inside the application that detects and blocks attacks in real time. Unlike a firewall (which protects the perimeter), RASP protects from within the application.
Why auditors care: RASP demonstrates runtime protection — a detective and corrective control that operates continuously, not just during testing phases.
Evidence to look for: RASP deployment configuration, blocked attack logs, alert/incident integration records, coverage reports.
Container / Image / Registry
What it is: A container is a lightweight, isolated package that bundles an application with everything it needs to run. An image is the template used to create containers. A registry is the repository where images are stored and distributed.
Why auditors care: Containers are the standard deployment unit in modern environments. Unsigned or unscanned images represent a supply chain risk. Registry access controls determine who can deploy what.
Evidence to look for: Image scanning reports, image signing/verification records, registry access control policies, base image update policies.
IaC (Infrastructure as Code)
What it is: Managing infrastructure (servers, networks, databases) through code files rather than manual configuration. Changes to infrastructure go through the same pipeline as application code.
Why auditors care: IaC makes infrastructure changes traceable, reviewable, and auditable — the same governance controls that apply to code can apply to infrastructure.
Evidence to look for: IaC templates in version control, change approval records, drift detection reports, security scanning of IaC templates.
Secrets Management
What it is: The practice of securely storing, distributing, and rotating sensitive credentials (API keys, passwords, certificates, tokens) used by applications and pipelines.
Why auditors care: Exposed secrets are one of the most common and severe security failures. Proper secrets management demonstrates access control maturity and reduces credential compromise risk.
Evidence to look for: Centralised vault/secrets manager deployment, automated rotation policies, no hardcoded secrets in code (verified by scanning), access audit logs.
Artifact
What it is: Any output produced by the CI/CD pipeline — compiled code, container images, packages, documentation. Artifacts are what gets deployed to production.
Why auditors care: Artifact integrity ensures that what was tested is exactly what gets deployed. Tampered or unsigned artifacts represent a critical supply chain risk.
Evidence to look for: Artifact signing records, provenance metadata, checksums/hashes, immutable artifact storage, deployment traceability back to specific pipeline runs.
Policy-as-Code
What it is: Encoding security and compliance policies as machine-readable rules that are automatically enforced by the CI/CD pipeline. Instead of a PDF policy document, the policy becomes executable code.
Why auditors care: Policy-as-code transforms policies from aspirational documents into enforced controls. It provides evidence that policies are not just written but actually applied.
Evidence to look for: Policy definition files in version control, enforcement logs showing policy evaluation results, records of deployments blocked by policy violations.
Shift-Left
What it is: Moving security testing and controls earlier in the software development lifecycle — from post-deployment (right) to design and coding phases (left). The goal is to catch issues when they are cheaper and easier to fix.
Why auditors care: Shift-left is evidence of a proactive, preventive security posture rather than a reactive one. Regulations increasingly expect security to be embedded throughout the SDLC, not bolted on at the end.
Evidence to look for: Security requirements in design documents, SAST integrated in developer workflows, threat modelling records, developer security training logs.
DevSecOps
What it is: An operating model that integrates security into every phase of software development and delivery. It defines roles, responsibilities, and automated controls to ensure security is continuous — not a separate phase or team.
Why auditors care: DevSecOps is the governance framework that makes CI/CD security sustainable. It determines who is responsible for what, how exceptions are handled, and how controls are enforced.
Evidence to look for: Defined roles and responsibilities (RACI), security gate configurations, exception/suppression approval workflows, security metrics and reporting cadence.
Segregation of Duties (SoD)
What it is: Ensuring that no single person can both develop code and approve its deployment to production. Different roles handle different stages of the delivery process.
Why auditors care: SoD is a fundamental control required by virtually every compliance framework. It prevents fraud, reduces insider threat risk, and ensures independent review.
Evidence to look for: RBAC configurations, approval workflow logs showing different approvers than code authors, branch protection rules, deployment permission matrices.
RBAC (Role-Based Access Control)
What it is: An access control model where permissions are assigned to roles (e.g., developer, reviewer, deployer) rather than individual users. Users inherit permissions through their role assignment.
Why auditors care: RBAC is the foundation for segregation of duties and least privilege. It provides a structured, auditable access model.
Evidence to look for: Role definitions and permission matrices, user-to-role assignment records, periodic access reviews, privileged role monitoring.
This glossary is maintained as a living reference. Terms are defined from the auditor’s perspective — focused on control verification, not implementation details. For technical implementation guidance, visit secure-pipelines.com.
