{"id":3216,"date":"2026-10-08T12:09:47","date_gmt":"2026-10-08T12:09:47","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/comptia-cas-005-sbom-sca-sast-dast-rasp\/"},"modified":"2026-10-18T15:44:18","modified_gmt":"2026-10-18T15:44:18","slug":"comptia-cas-005-sbom-sca-sast-dast-rasp","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/comptia-cas-005-sbom-sca-sast-dast-rasp\/","title":{"rendered":"CompTIA CAS-005: SBOM, SCA, SAST, DAST, and RASP"},"content":{"rendered":"

Modern application security uses several tools that sound similar but observe different evidence. A software bill of materials (SBOM) inventories components. Software composition analysis (SCA) evaluates third-party and open-source dependencies. Static application security testing (SAST) analyzes code or related representations without executing the application. Dynamic application security testing (DAST) tests a running application from the outside. Runtime application self-protection (RASP) operates with the application at runtime. The current CompTIA SecurityX CAS-005<\/a> objectives place these techniques together under software assurance because no single one covers the full software supply chain.<\/p>\n

Choosing among them is not a contest for one \u201cbest\u201d scanner. The useful question is which blind spot each technique closes and where in the software lifecycle it can provide feedback. Strong programs combine early developer feedback, dependency visibility, pre-release testing, production safeguards, and a process for deciding which findings actually block a release.<\/p>\n

An SBOM is an inventory, not a vulnerability verdict<\/h2>\n

An SBOM records software components and relationships so an organization can answer questions such as which products contain a particular library or version. Useful records may include package names, versions, suppliers, hashes, dependency relationships, and identifiers that let security tools correlate a component with vulnerability intelligence.<\/p>\n

The inventory becomes especially valuable when a new dependency vulnerability is disclosed. Instead of asking every development team from memory, security can query the inventory and identify affected products. However, the presence of a component does not prove exploitability. Reachability, configuration, packaging, runtime use, and compensating controls still matter.<\/p>\n

SCA turns dependency metadata into software-risk findings<\/h2>\n

SCA examines third-party components and compares them with vulnerability, license, and policy data. It can run during development, CI\/CD, artifact scanning, or repository analysis. Because modern applications may contain hundreds or thousands of transitive dependencies, automated SCA is far more scalable than manual library review.<\/p>\n

False urgency is a real problem. A vulnerable package may be present but unreachable from the application\u2019s execution path, while another library with a lower severity score may be internet exposed and easily exploited. SCA findings should therefore be enriched with deployment and exploitability context. The tool identifies dependency risk; engineering still decides remediation priority.<\/p>\n

SAST finds code patterns before the application runs<\/h2>\n

SAST analyzes source code, bytecode, or related representations to find insecure coding patterns<\/a>, dangerous data flows, injection risks, weak cryptographic use, and other implementation issues. It can provide feedback early, sometimes directly in an integrated development environment or pull request. That makes it attractive for \u201cshift left\u201d programs.<\/p>\n

Static analysis can struggle with framework behavior, generated code, reflection, configuration, and complex data flows. A noisy rule set may overwhelm developers, while an overly narrow set misses important classes. Tune rules to the languages and frameworks actually in use, suppress findings with documented rationale, and keep secure coding guidance close to the developer workflow.<\/p>\n

DAST tests the behavior of a running application<\/h2>\n

DAST interacts with a deployed application through exposed interfaces, so it can find issues that emerge from runtime configuration, routing, authentication flows, headers, and actual input handling. The scanner does not need the application source to test externally visible behavior, which makes it useful against staging environments and acquired applications.<\/p>\n

Because DAST sees the system from the outside, it may have limited insight into the exact code location that caused a finding. Coverage also depends on crawling, authentication, API discovery, and test data. A scanner that cannot reach authenticated routes may report a clean result while missing the most sensitive functionality. Treat environment preparation as part of the test.<\/p>\n

RASP observes and can block behavior inside the running process<\/h2>\n

RASP instruments or integrates with an application so it can evaluate behavior with runtime context. Depending on the technology, it may identify and block exploit patterns, observe data flows, or enforce protection near vulnerable code paths. This gives it visibility that an external scanner does not have.<\/p>\n

Runtime protection is not a substitute for fixing defects. It adds a production control that can reduce exploitation risk while remediation is underway, but it also introduces performance, compatibility, and operational considerations. Teams should understand whether a RASP action blocks, logs, or modifies requests and how to troubleshoot an application when the protection layer intervenes.<\/p>\n

IAST and other techniques can bridge static and dynamic evidence<\/h3>\n

The CAS-005 objectives also include interactive application security testing (IAST). IAST typically observes application behavior from inside while tests exercise the application, combining runtime context with code-level visibility. This can improve finding precision for certain classes of defects and show how inputs actually propagate through the application.<\/p>\n

The broader lesson is that security testing forms a portfolio. Fuzzing, API testing, penetration testing, manual code review, secrets scanning, container scanning, and infrastructure-as-code analysis may all add value depending on the system. Do not force one product to claim coverage for every software assurance problem.<\/p>\n

Place controls at multiple points in CI\/CD<\/h2>\n

Fast feedback should happen before merge where possible. Lightweight SAST, secrets checks, dependency policy, and unit-level security tests can run on pull requests. More expensive SAST configurations, SCA, image scanning, and integration security tests can run during build. DAST and IAST can run against a deployable staging environment. Production can add runtime monitoring and RASP where justified.<\/p>\n

Gates should be risk based. Blocking every low-confidence finding encourages developers to bypass the program. Define which severity, exploitability, asset sensitivity, and policy conditions stop a release. Give teams a documented exception process with an owner and expiration date so necessary business releases do not create permanent invisible risk acceptance.<\/p>\n

Software supply-chain security needs provenance as well as scanning<\/h2>\n

Scanning an artifact does not prove where it came from. Protect source repositories, build runners, package registries, signing keys, and deployment identities. Generate artifacts in controlled pipelines, record provenance, and verify signatures or attestations where the platform supports them. A clean SAST report is irrelevant if an attacker can replace the artifact after scanning.<\/p>\n

SBOM generation should be tied to the actual released artifact rather than a developer workstation snapshot. That improves incident response because the inventory reflects what customers or production systems received. Rebuilds should be reproducible enough that teams can explain why two artifacts with the same version label differ.<\/p>\n

Use findings to drive engineering decisions, not dashboard volume<\/h3>\n

A mature program correlates SAST, SCA, DAST, runtime telemetry, asset context, and production exposure. Duplicate findings should be grouped, root causes should be identified, and remediation should focus on changes that eliminate classes of problems. Metrics such as time to remediate and recurrence rate are often more useful than the raw number of scanner findings.<\/p>\n

Software assurance is fundamentally an engineering discipline across the secure software development lifecycle (SDLC). An SBOM tells you what is present; SCA tells you what dependencies may be risky; SAST inspects code without executing it; DAST tests the running surface; and RASP adds runtime context and protection. The strongest program understands exactly what evidence each control can and cannot provide, then feeds that evidence back to the team that can fix the underlying software.<\/p>\n

Design the feedback loop so developers can act on findings<\/h2>\n

Security tooling fails when findings arrive without enough context to repair them. Developer-facing results should identify the affected component or code path, explain the weakness, show the evidence that triggered it, and point to an approved remediation pattern. A long export of scanner terminology creates queue volume rather than secure software.<\/p>\n

Deduplicate related findings across tools. A vulnerable package may be reported by repository SCA, container scanning, and runtime inventory; treat those as evidence about one underlying dependency rather than three independent defects. Conversely, do not merge findings only because they share a vulnerability identifier if the affected applications have different exposure and business impact.<\/p>\n

Create service-level expectations that reflect risk. Internet-exposed exploitable flaws in an authentication service should move faster than a low-confidence issue in an isolated test utility. Teams need a transparent escalation and exception process so security can distinguish accepted risk from work that simply fell out of the backlog.<\/p>\n

Feed remediation lessons back into engineering standards. If the same injection class appears across services, strengthen secure libraries, framework defaults, code templates, and tests so new code avoids the pattern automatically. The long-term goal is not to scan more often; it is to make entire classes of insecure implementation harder to create.<\/p>\n

Tool ownership should be clear too. Development teams may own immediate code fixes, platform teams may own base images and build runners, and security teams may own enterprise rule sets and risk policy. When ownership is ambiguous, findings bounce between queues until deadlines expire. Map common finding types to an accountable team before the volume becomes large.<\/p>\n

Retest closed findings. A developer may remove the visible symptom while leaving an alternate vulnerable path, or a dependency upgrade may reintroduce a transitive package through another component. Automated regression tests and rescanning after remediation provide evidence that the risk was actually reduced. Closure should mean verified change, not simply a ticket status.<\/p>\n

Security evidence should remain reproducible. Preserve scanner versions, relevant rule sets, dependency lock files, build identifiers, and the artifact hash associated with important findings. When a later release appears to \u201cfix\u201d a vulnerability, the team should be able to prove which artifact was tested and which controls changed rather than relying on a dashboard whose underlying scan inputs have already moved on.<\/p>\n","protected":false},"excerpt":{"rendered":"

Modern application security uses several tools that sound similar but observe different evidence. A software bill of materials (SBOM) inventories components. Software composition analysis (SCA) […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,49,109],"tags":[],"class_list":["post-3216","post","type-post","status-publish","format-standard","hentry","category-certifications","category-comptia-certifications","category-exam-cas-005"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3216","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3216"}],"version-history":[{"count":2,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3216\/revisions"}],"predecessor-version":[{"id":4767,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3216\/revisions\/4767"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3216"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3216"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3216"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}