Explore all React2Shell and framework vulnerability guides →
Use software composition analysis, or SCA, to investigate known vulnerabilities in your application's dependencies. Use dynamic application security testing, or DAST, to assess observable behavior in a running application. For a newly disclosed CVE, you may need both, plus deployment evidence. Neither a package alert nor a clean URL scan answers every question about your website's exposure.
SCA starts with components and advisory data
OWASP describes SCA as identifying third-party libraries and dependencies and checking them for known vulnerabilities. Its usefulness depends on what it can inventory and the advisory information available to it. A source repository, a built container and an installed application can contain different component sets, so record exactly which artifact the result describes.
Before acting on an alert, check the package identity, resolved version and advisory's conditions. Identify whether the component ships in the service you are reviewing or is limited to another stage of your workflow. Do not dismiss a build dependency automatically; determine its actual use and trust boundary. Keep the deployment question attached to the alert instead of assuming the default branch is already live.
DAST starts with a reachable application
OWASP's dynamic-testing guidance describes examining a running application through requests and responses. This can reveal runtime behavior and configuration issues that a dependency inventory cannot show. The result is bounded by the tool's implemented checks, accessible routes, supplied identities and test conditions.
A dynamic check may be unable to observe a vulnerable library hidden behind a feature it did not reach. It may also identify a security problem in application code that has no published CVE at all. For that reason, compare the questions each assessment asked before comparing the number of findings.
Resolve apparently conflicting results
- SCA reports an affected package; DAST reports no findings: verify advisory applicability and the deployed component. Check whether DAST actually included a relevant test. Do not let the empty dynamic report cancel the package evidence.
- DAST reports a vulnerability; SCA reports no known vulnerable dependencies: investigate the runtime evidence. Custom application behavior or configuration may be responsible.
- The repository is patched; the live site remains uncertain: map the active deployment to its build and resolved dependencies before closing the issue.
- Both tools report nothing: review inventory completeness, advisory freshness, test coverage and inaccessible paths. Record the scope of the conclusion.
Use a simple evidence handoff between teams
The dependency owner supplies the advisory, component identity, installed version and affected-service decision. The release owner supplies the build identifier and proof of the active deployment. The assessment owner supplies the target, timestamp, relevant result and coverage limits. Put these records in one ticket so a reviewer can connect them without reconstructing a chat history.
For example, if an advisory concerns a server framework, start by identifying that framework in the deployed artifact. Apply the vendor's supported fix when applicable. Then use scoped runtime testing to assess relevant observable behavior and release regressions. If safe, specific validation is unavailable, state that limitation instead of running an unreviewed exploit against production to obtain a binary answer.
Where MyPentest fits
Run MyPentest on your authorized website for a baseline of supported runtime checks, then review findings, passed checks and unchecked coverage. Keep your dependency inventory and vendor advisory review alongside that report. This article does not establish that MyPentest performs source-level SCA or detects a particular new CVE. Without documented applicable coverage, the specific CVE result remains unknown from the website scan alone.