{"id":2001,"date":"2026-01-10T11:35:14","date_gmt":"2026-01-10T10:35:14","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/controles-de-pruebas-de-seguridad-ci-cd-sast-dast-y-sca-desde-la-perspectiva-del-auditor\/"},"modified":"2026-03-26T09:36:32","modified_gmt":"2026-03-26T08:36:32","slug":"controles-de-pruebas-de-seguridad-ci-cd-sast-dast-y-sca-desde-la-perspectiva-del-auditor","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/es\/tool-governance-es\/controles-de-pruebas-de-seguridad-ci-cd-sast-dast-y-sca-desde-la-perspectiva-del-auditor\/","title":{"rendered":"Controles de Pruebas de Seguridad CI\/CD \u2014 SAST, DAST y SCA desde la Perspectiva del Auditor"},"content":{"rendered":"\n<p><strong>Comparing CI\/CD Security Testing Controls: What Auditors, Compliance Officers, and Regulators Need to Know<\/strong><\/p>\n\n<p>Security testing controls in CI\/CD pipelines \u2014 commonly referred to as SAST, DAST, and SCA \u2014 are frequently compared based on technical detection capabilities. For auditors and compliance officers, the relevant comparison dimensions are different: <strong>control objectives, evidence quality, enforcement capability, audit traceability, and compliance framework alignment<\/strong>.<\/p>\n\n<p>This article compares SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and SCA (Software Composition Analysis) from a governance and audit perspective, helping auditors understand what each control does, what evidence it should produce, and how to verify it is properly implemented.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>SAST \u2014 Control Properties for Auditors<\/strong><\/h2>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Control Property<\/strong><\/th><th><strong>SAST (Static Application Security Testing)<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Control objective<\/td><td>Detect security vulnerabilities in source code before deployment<\/td><\/tr><tr><td>Evidence quality<\/td><td>High \u2014 produces detailed scan reports with severity classifications and policy pass\/fail decisions<\/td><\/tr><tr><td>CI\/CD enforcement capability<\/td><td>Strong \u2014 can block builds and prevent deployment when thresholds are exceeded<\/td><\/tr><tr><td>Audit traceability<\/td><td>High \u2014 results can be linked to specific builds, commits, and releases<\/td><\/tr><tr><td>Compliance framework alignment<\/td><td>DORA (preventive coding control), NIS2 (secure SDLC), ISO 27001 (A.8.25-28), SOC 2 (CC8.1), PCI DSS (6.3)<\/td><\/tr><tr><td>Governance requirements<\/td><td>Defined severity thresholds, documented suppression policies, retention of scan results<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p><strong>What Auditors Should Verify for SAST:<\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>SAST executes automatically on every build or pull request \u2014 not on demand only<\/li>\n\n\n\n<li>Severity thresholds are defined and enforced (builds fail when thresholds are breached)<\/li>\n\n\n\n<li>Suppressed findings have documented justifications with review dates and expiration<\/li>\n\n\n\n<li>Scan results are retained and linked to specific releases<\/li>\n\n\n\n<li>All production codebases are covered by SAST scanning<\/li>\n<\/ul>\n\n<p><strong>Red Flags for SAST:<\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>SAST is configured but not enforced \u2014 builds proceed regardless of findings<\/li>\n\n\n\n<li>Large numbers of suppressed findings without documented rationale or expiration dates<\/li>\n\n\n\n<li>Scan results cannot be traced to specific releases or builds<\/li>\n\n\n\n<li>Production codebases exist that are not covered by SAST scanning<\/li>\n\n\n\n<li>SAST runs only on demand rather than automatically as part of every build<\/li>\n<\/ul>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>DAST \u2014 Control Properties for Auditors<\/strong><\/h2>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Control Property<\/strong><\/th><th><strong>DAST (Dynamic Application Security Testing)<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Control objective<\/td><td>Validate runtime security of deployed or staged applications<\/td><\/tr><tr><td>Evidence quality<\/td><td>Medium to high \u2014 produces runtime findings but may require context to interpret<\/td><\/tr><tr><td>CI\/CD enforcement capability<\/td><td>Medium \u2014 typically used as a release gate, not a build-time gate<\/td><\/tr><tr><td>Audit traceability<\/td><td>Medium \u2014 results are linked to environments and releases, but tracing to specific code changes is indirect<\/td><\/tr><tr><td>Compliance framework alignment<\/td><td>DORA (runtime validation), ISO 27001 (A.8.25-28), SOC 2 (CC7.1), PCI DSS (6.4, 11.3)<\/td><\/tr><tr><td>Governance requirements<\/td><td>Defined execution points, documented gating logic, exception and approval workflows<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p><strong>What Auditors Should Verify for DAST:<\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>DAST runs before production releases, not only on demand or on a schedule disconnected from deployments<\/li>\n\n\n\n<li>Defined thresholds exist for blocking or delaying releases<\/li>\n\n\n\n<li>Exceptions to DAST gating are documented with approvals and justifications<\/li>\n\n\n\n<li>False positive management follows a governed process (role-based suppression, documented rationale, expiration)<\/li>\n\n\n\n<li>DAST scope covers all externally facing and critical applications<\/li>\n<\/ul>\n\n<p><strong>Red Flags for DAST:<\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>DAST runs only occasionally or on a schedule disconnected from the release process<\/li>\n\n\n\n<li>No gating logic exists \u2014 all releases proceed regardless of DAST findings<\/li>\n\n\n\n<li>DAST results cannot be linked to specific deployments or releases<\/li>\n\n\n\n<li>Externally facing or critical applications are excluded from DAST scope<\/li>\n\n\n\n<li>False positives are suppressed without documented approvals or expiration dates<\/li>\n<\/ul>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>SCA \u2014 Control Properties for Auditors<\/strong><\/h2>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Control Property<\/strong><\/th><th><strong>SCA (Software Composition Analysis)<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Control objective<\/td><td>Manage third-party and supply chain risk by identifying vulnerable and non-compliant dependencies<\/td><\/tr><tr><td>Evidence quality<\/td><td>Very high \u2014 produces dependency inventories, SBOMs, vulnerability reports, and license compliance records<\/td><\/tr><tr><td>CI\/CD enforcement capability<\/td><td>Strong \u2014 can block builds when vulnerable or non-compliant dependencies are detected<\/td><\/tr><tr><td>Audit traceability<\/td><td>Very high \u2014 SBOMs and dependency inventories provide clear, auditable records per release<\/td><\/tr><tr><td>Compliance framework alignment<\/td><td>NIS2 (supply chain risk), DORA (ICT third-party risk), ISO 27001 (A.8.25-28), SOC 2 (CC3.2), PCI DSS (6.3)<\/td><\/tr><tr><td>Governance requirements<\/td><td>Dependency approval policies, SBOM generation and retention, vulnerability response procedures<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p><strong>What Auditors Should Verify for SCA:<\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>SCA runs automatically during builds and produces current dependency inventories<\/li>\n\n\n\n<li>SBOMs are generated and retained for each release<\/li>\n\n\n\n<li>Known vulnerable dependencies trigger defined responses (blocking, alerting, or documented risk acceptance)<\/li>\n\n\n\n<li>License compliance is actively monitored and violations are addressed<\/li>\n\n\n\n<li>Dependency policies define acceptable components and approval processes for exceptions<\/li>\n<\/ul>\n\n<p><strong>Red Flags for SCA:<\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>No dependency inventory or SBOM exists for production applications<\/li>\n\n\n\n<li>Known critical vulnerabilities in dependencies are not addressed or documented<\/li>\n\n\n\n<li>SCA is not integrated into CI\/CD \u2014 it runs manually or not at all<\/li>\n\n\n\n<li>No governance over which third-party components may be used<\/li>\n\n\n\n<li>License compliance is not monitored, creating legal and regulatory risk<\/li>\n<\/ul>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Side-by-Side Comparison: SAST vs DAST vs SCA from an Audit Perspective<\/strong><\/h2>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Audit Dimension<\/strong><\/th><th class=\"has-text-align-center\" data-align=\"center\"><strong>SAST<\/strong><\/th><th class=\"has-text-align-center\" data-align=\"center\"><strong>DAST<\/strong><\/th><th class=\"has-text-align-center\" data-align=\"center\"><strong>SCA<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Control objective<\/td><td class=\"has-text-align-center\" data-align=\"center\">Preventive code-level security<\/td><td class=\"has-text-align-center\" data-align=\"center\">Runtime validation<\/td><td class=\"has-text-align-center\" data-align=\"center\">Supply chain risk management<\/td><\/tr><tr><td>Evidence quality<\/td><td class=\"has-text-align-center\" data-align=\"center\">High<\/td><td class=\"has-text-align-center\" data-align=\"center\">Medium-High<\/td><td class=\"has-text-align-center\" data-align=\"center\">Very High<\/td><\/tr><tr><td>CI\/CD enforcement capability<\/td><td class=\"has-text-align-center\" data-align=\"center\">Strong (build gating)<\/td><td class=\"has-text-align-center\" data-align=\"center\">Medium (release gating)<\/td><td class=\"has-text-align-center\" data-align=\"center\">Strong (dependency blocking)<\/td><\/tr><tr><td>Audit traceability<\/td><td class=\"has-text-align-center\" data-align=\"center\">High (commit-linked)<\/td><td class=\"has-text-align-center\" data-align=\"center\">Medium (environment-linked)<\/td><td class=\"has-text-align-center\" data-align=\"center\">Very High (SBOM-linked)<\/td><\/tr><tr><td>Compliance framework alignment<\/td><td class=\"has-text-align-center\" data-align=\"center\">Broad<\/td><td class=\"has-text-align-center\" data-align=\"center\">Broad<\/td><td class=\"has-text-align-center\" data-align=\"center\">Critical for supply chain regulations<\/td><\/tr><tr><td>Governance complexity<\/td><td class=\"has-text-align-center\" data-align=\"center\">Medium (suppression management)<\/td><td class=\"has-text-align-center\" data-align=\"center\">Medium-High (false positive governance)<\/td><td class=\"has-text-align-center\" data-align=\"center\">Medium (dependency policy management)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Which Controls Matter Most Under Each Regulation<\/strong><\/h2>\n\n<h3 class=\"wp-block-heading\"><strong>DORA (Digital Operational Resilience Act)<\/strong><\/h3>\n\n<p>DORA emphasizes ICT risk management and operational resilience for financial entities. From an audit perspective:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>SCA is critical<\/strong> \u2014 DORA requires visibility into ICT third-party risk, including software dependencies<\/li>\n\n\n\n<li><strong>SAST is important<\/strong> \u2014 supports preventive controls within the secure development lifecycle<\/li>\n\n\n\n<li><strong>DAST provides supplementary validation<\/strong> \u2014 demonstrates runtime testing of deployed services<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\"><strong>NIS2 (Network and Information Security Directive)<\/strong><\/h3>\n\n<p>NIS2 focuses on supply chain security, incident handling, and risk management for essential and important entities:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>SCA is essential<\/strong> \u2014 directly addresses supply chain and dependency risk requirements<\/li>\n\n\n\n<li><strong>SAST supports secure development<\/strong> \u2014 aligns with requirements for secure-by-design practices<\/li>\n\n\n\n<li><strong>DAST validates service exposure<\/strong> \u2014 helps demonstrate that externally facing services are tested<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\"><strong>ISO 27001<\/strong><\/h3>\n\n<p>ISO 27001 requires organizations to demonstrate control effectiveness across the information security management system:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>All three controls are relevant<\/strong> \u2014 they collectively demonstrate secure development practices (Annex A controls A.8.25\u201328)<\/li>\n\n\n\n<li><strong>SCA often provides the clearest evidence<\/strong> \u2014 SBOMs and dependency inventories are tangible, auditable artifacts<\/li>\n\n\n\n<li>Auditors should verify that controls are <strong>integrated into CI\/CD<\/strong>, not performed as separate manual activities<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\"><strong>SOC 2<\/strong><\/h3>\n\n<p>SOC 2 evaluates controls related to security, availability, processing integrity, confidentiality, and privacy:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>SAST and SCA<\/strong> support the Security and Processing Integrity trust service criteria<\/li>\n\n\n\n<li><strong>DAST<\/strong> supports evidence of runtime security testing<\/li>\n\n\n\n<li>Auditors should focus on whether controls are <strong>consistently enforced and produce retained evidence<\/strong><\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\"><strong>PCI DSS<\/strong><\/h3>\n\n<p>PCI DSS has explicit requirements for application security testing:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>SAST is directly referenced<\/strong> (Requirement 6.3) \u2014 code reviews or automated code analysis are required<\/li>\n\n\n\n<li><strong>DAST is directly referenced<\/strong> (Requirements 6.4, 11.3) \u2014 web application security testing is mandatory<\/li>\n\n\n\n<li><strong>SCA supports<\/strong> vulnerability management requirements by tracking known vulnerabilities in dependencies<\/li>\n<\/ul>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Practical Guidance for Auditors<\/strong><\/h2>\n\n<ul class=\"wp-block-list\">\n<li><strong>No single control is sufficient<\/strong> \u2014 organizations should demonstrate a layered approach<\/li>\n\n\n\n<li><strong>SAST and SCA are foundational<\/strong> \u2014 they should be present in every mature CI\/CD pipeline<\/li>\n\n\n\n<li><strong>DAST adds runtime validation<\/strong> but should not be the only testing control<\/li>\n\n\n\n<li><strong>CI\/CD enforcement matters more than scan depth<\/strong> \u2014 a control that runs but does not gate is weak<\/li>\n\n\n\n<li><strong>Evidence quality matters more than vulnerability count<\/strong> \u2014 look for traceability, retention, and governance<\/li>\n<\/ul>\n\n<p>The most auditable pipelines use:<\/p>\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><strong>SAST + SCA enforced by default, DAST at defined control points, with all results retained and traceable.<\/strong><\/p>\n<\/blockquote>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Conclusion<\/strong><\/h2>\n\n<p>SAST, DAST, and SCA serve different but complementary control objectives within CI\/CD pipelines. For auditors, the value of each control lies not in its detection capabilities, but in its <strong>enforcement, evidence quality, traceability, and alignment with applicable regulations<\/strong>.<\/p>\n\n<p>When assessing CI\/CD security testing controls, focus on: <strong>Is the control enforced? Does it produce reliable evidence? Can that evidence be traced to specific releases? And is governance in place for exceptions and suppressions?<\/strong><\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Related for Auditors<\/strong><\/h2>\n\n<ul class=\"wp-block-list\">\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/glossary\/\">Glossary of CI\/CD Security and Compliance Terms<\/a><\/strong><\/li>\n\n\n\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/ci-cd-security-tools-controls-mapping\/\">CI\/CD Security Tools \u2014 Controls Mapping<\/a><\/strong><\/li>\n\n\n\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/dual-compliance-architecture-explained\/\">Dual Compliance Architecture Explained<\/a><\/strong><\/li>\n\n\n\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/how-auditors-actually-review-ci-cd-pipelines\/\">How Auditors Actually Review CI\/CD Pipelines<\/a><\/strong><\/li>\n<\/ul>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n    <section class=\"rds-author-box rds-author-box--standard\"\r\n             dir=\"ltr\" lang=\"es\"\r\n             style=\"border:1px solid rgba(100,116,139,.35);border-radius:14px;padding:16px 18px;margin:26px 0 18px;background:rgba(148,163,184,.08);\">\r\n      <strong style=\"margin:0 0 8px; font-size:14px; font-weight:700; letter-spacing:.02em;\">Sobre el autor<\/strong>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">Arquitecto senior DevSecOps y de seguridad, con m\u00e1s de 15 a\u00f1os de experiencia en ingenier\u00eda de software segura, seguridad CI\/CD y entornos empresariales regulados.<\/p>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">Certificado CSSLP y EC-Council Certified DevSecOps Engineer, con experiencia pr\u00e1ctica dise\u00f1ando arquitecturas CI\/CD seguras, auditables y conformes.<\/p>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">\r\n        <a href=\"https:\/\/regulated-devsecops.com\/es\/es\/about\/\">M\u00e1s informaci\u00f3n en la p\u00e1gina About.<\/a>\r\n      <\/p>\r\n    <\/section>\r\n    \n","protected":false},"excerpt":{"rendered":"<p>Comparaci\u00f3n de SAST, DAST y SCA desde la perspectiva del auditor: objetivos de control, calidad de evidencia, capacidad de aplicaci\u00f3n en CI\/CD y alineaci\u00f3n con DORA, NIS2, ISO 27001, SOC 2 y PCI DSS.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[137,131,132],"tags":[],"post_folder":[],"class_list":["post-2001","post","type-post","status-publish","format-standard","hentry","category-tool-governance-es","category-audit-evidence-es","category-ci-cd-governance-es"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/2001","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/comments?post=2001"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/2001\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/media?parent=2001"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/categories?post=2001"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/tags?post=2001"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/post_folder?post=2001"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}