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)
Ce que c’est : 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.
Pourquoi les auditeurs s’en soucient : 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.
Preuves à rechercher : Pipeline execution logs with timestamps, mandatory stage completion records, approval workflows before production deployment.
Pipeline
Ce que c’est : A sequence of automated steps (build, test, scan, deploy) that code must pass through before reaching production. Each step can enforce a security gate.
Pourquoi les auditeurs s’en soucient : The pipeline architecture determines whether security controls are mandatory or optional. A well-designed pipeline prevents unapproved code from reaching production.
Preuves à rechercher : Pipeline configuration files showing mandatory stages, gate pass/fail logs, records of blocked deployments.
SAST (Static Application Security Testing)
Ce que c’est : 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.
Pourquoi les auditeurs s’en soucient : SAST fournit la preuve que les tests de sécurité se font tôt dans le développement. Il démontre que l’organisation identifie proactivement les vulnérabilités plutôt que de les découvrir en production.
Preuves à rechercher : Journaux de scan avec horodatages, application de politique montrant les builds bloqués sur les constats critiques, rapports de tendance montrant les taux de remédiation dans le temps, processus de suppression/exception documentés.
DAST (Dynamic Application Security Testing)
Ce que c’est : Test automatisé d’une application en cours d’exécution en simulant de vraies attaques. Contrairement au SAST (qui lit le code), le DAST teste l’application comme le ferait un attaquant — de l’extérieur.
Pourquoi les auditeurs s’en soucient : Le DAST valide que les applications déployées sont résilientes face aux modèles d’attaque connus. Il complète le SAST en testant le comportement réel, pas seulement le code.
Preuves à rechercher : Rapports de scan DAST avec vulnérabilités identifiées et niveaux de gravité, calendriers de remédiation, planifications de scans récurrents, intégration avec les journaux du pipeline CI/CD.
SCA (Software Composition Analysis)
Ce que c’est : Analyse automatisée des bibliothèques tierces et dépendances utilisées dans le logiciel. La plupart des applications modernes sont composées de 70 à 90 % de code tiers — le SCA vérifie si ce code présente des vulnérabilités connues ou des risques de licence.
Pourquoi les auditeurs s’en soucient : Le risque des composants tiers est une préoccupation majeure selon l’article 28 de DORA et les exigences de chaîne d’approvisionnement de NIS2. Le SCA fournit une visibilité sur la chaîne d’approvisionnement logicielle.
Preuves à rechercher : Inventaires de dépendances, rapports de vulnérabilités pour les composants tiers, vérifications de conformité de licence, blocage automatisé des composants avec des vulnérabilités critiques.
SBOM (Software Bill of Materials)
Ce que c’est : Un inventaire complet et lisible par machine de chaque composant (bibliothèques, frameworks, dépendances) inclus dans une application logicielle. Pensez-y comme une étiquette nutritionnelle pour le logiciel.
Pourquoi les auditeurs s’en soucient : Les SBOM sont de plus en plus exigés par la réglementation. Ils permettent la traçabilité des composants de la chaîne d’approvisionnement et l’évaluation rapide de l’impact lorsque de nouvelles vulnérabilités sont divulguées.
Preuves à rechercher : Fichiers SBOM générés (format SPDX ou CycloneDX), génération automatisée de SBOM dans les pipelines CI/CD, enregistrements de rétention et de versioning des SBOM.
IAST (Interactive Application Security Testing)
Ce que c’est : Une approche de test hybride qui surveille les applications de l’intérieur pendant les tests. Un agent est intégré dans l’application et observe les chemins d’exécution réels du code pour identifier les vulnérabilités avec une grande précision.
Pourquoi les auditeurs s’en soucient : IAST provides highly accurate results with fewer false positives than SAST or DAST alone, which means findings are more actionable and auditable.
Preuves à rechercher : IAST agent deployment records, test execution reports, vulnerability findings correlated with specific code paths.
RASP (Runtime Application Self-Protection)
Ce que c’est : 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.
Pourquoi les auditeurs s’en soucient : RASP demonstrates runtime protection — a detective and corrective control that operates continuously, not just during testing phases.
Preuves à rechercher : RASP deployment configuration, blocked attack logs, alert/incident integration records, coverage reports.
Container / Image / Registry
Ce que c’est : 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.
Pourquoi les auditeurs s’en soucient : 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.
Preuves à rechercher : Image scanning reports, image signing/verification records, registry access control policies, base image update policies.
IaC (Infrastructure as Code)
Ce que c’est : Managing infrastructure (servers, networks, databases) through code files rather than manual configuration. Changes to infrastructure go through the same pipeline as application code.
Pourquoi les auditeurs s’en soucient : IaC makes infrastructure changes traceable, reviewable, and auditable — the same governance controls that apply to code can apply to infrastructure.
Preuves à rechercher : IaC templates in version control, change approval records, drift detection reports, security scanning of IaC templates.
Secrets Management
Ce que c’est : The practice of securely storing, distributing, and rotating sensitive credentials (API keys, passwords, certificates, tokens) used by applications and pipelines.
Pourquoi les auditeurs s’en soucient : Exposed secrets are one of the most common and severe security failures. Proper secrets management demonstrates access control maturity and reduces credential compromise risk.
Preuves à rechercher : Centralised vault/secrets manager deployment, automated rotation policies, no hardcoded secrets in code (verified by scanning), access audit logs.
Artifact
Ce que c’est : Any output produced by the CI/CD pipeline — compiled code, container images, packages, documentation. Artifacts are what gets deployed to production.
Pourquoi les auditeurs s’en soucient : Artifact integrity ensures that what was tested is exactly what gets deployed. Tampered or unsigned artifacts represent a critical supply chain risk.
Preuves à rechercher : Artifact signing records, provenance metadata, checksums/hashes, immutable artifact storage, deployment traceability back to specific pipeline runs.
Policy-as-Code
Ce que c’est : 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.
Pourquoi les auditeurs s’en soucient : Policy-as-code transforms policies from aspirational documents into enforced controls. It provides evidence that policies are not just written but actually applied.
Preuves à rechercher : Policy definition files in version control, enforcement logs showing policy evaluation results, records of deployments blocked by policy violations.
Shift-Left
Ce que c’est : 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.
Pourquoi les auditeurs s’en soucient : 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.
Preuves à rechercher : Security requirements in design documents, SAST integrated in developer workflows, threat modelling records, developer security training logs.
DevSecOps
Ce que c’est : 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.
Pourquoi les auditeurs s’en soucient : 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.
Preuves à rechercher : Defined roles and responsibilities (RACI), security gate configurations, exception/suppression approval workflows, security metrics and reporting cadence.
Segregation of Duties (SoD)
Ce que c’est : Ensuring that no single person can both develop code and approve its deployment to production. Different roles handle different stages of the delivery process.
Pourquoi les auditeurs s’en soucient : SoD is a fundamental control required by virtually every compliance framework. It prevents fraud, reduces insider threat risk, and ensures independent review.
Preuves à rechercher : RBAC configurations, approval workflow logs showing different approvers than code authors, branch protection rules, deployment permission matrices.
RBAC (Role-Based Access Control)
Ce que c’est : 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.
Pourquoi les auditeurs s’en soucient : RBAC is the foundation for segregation of duties and least privilege. It provides a structured, auditable access model.
Preuves à rechercher : 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.
