SAST and DAST
Automated security testing - SAST analyzes source code at rest, DAST exercises a running application.
Definition
Static Application Security Testing (SAST) analyzes source code, bytecode, or binaries without executing them, looking for known vulnerable patterns (SQL injection, buffer overflows, hardcoded secrets, insecure crypto). Dynamic Application Security Testing (DAST) probes a running application from the outside, exercising authenticated and unauthenticated paths to find runtime issues (auth bypass, injection, misconfiguration). Together they cover complementary parts of the OWASP testing surface and are baseline tooling for any modern CI/CD pipeline.What this means in practice
SAST belongs in the developer's PR check (Semgrep, CodeQL, SonarQube, Checkmarx). DAST belongs in nightly or release-gate CI (OWASP ZAP, Burp Suite, Invicti). Both produce noise; mature teams tune rule sets, baseline known issues, and route real findings into the CAPA and security-fix workflow rather than dumping the raw tool output into the submission.Examples
- Before a code change is merged, a developer uses SAST to identify a potential buffer overflow vulnerability in a C++ module, prompting an immediate fix.
- During nightly automated builds, DAST is run against the staging environment of a new MedTech application, detecting a misconfiguration that allows unauthorized access to patient data through a specific API endpoint.
- A MedTech device manufacturer employs both SAST and DAST within its development pipeline; SAST catches an insecure cryptographic algorithm during code review, while DAST later confirms the absence of session management flaws in the deployed system.
- •Submitting raw tool output without triage - reviewers cannot tell signal from noise.
- •Running SAST/DAST only at submission rather than continuously through the build pipeline.
- •Skipping SCA (Software Composition Analysis) - SAST finds your code's bugs, SCA finds your dependencies' bugs.
Frequently asked questions
Related terms
Grouped by themeEditor's picks
· Hand-selected related conceptsInternational standard defining secure-product-lifecycle activities for health software, including medical devices.
Hands-on adversarial testing in which qualified independent testers attempt to exploit a device's security controls.
The bundle of cybersecurity artifacts a sponsor includes in a 510(k), De Novo, PMA, or HDE submission for a cyber device.
The federal statute that gives FDA explicit premarket authority over cybersecurity for cyber devices.
More in Cybersecurity
· Same categoryA documented, risk-based set of processes that build cybersecurity into a medical device across its full lifecycle.
AAMI/ANSI standard establishing requirements for medical-device cybersecurity activities throughout the lifecycle.
AAMI Technical Information Report providing MedTech-specific guidance on cybersecurity risk management.
AAMI Technical Information Report on post-market security risk management for medical device manufacturers, the operational companion to TIR57.
Where this term appears across MedTech Terms.
Latest in MedTech
Sources
3 sourcesSources support the definition or relevant regulatory context, not necessarily every claim on this page. Each is graded against our source-tier hierarchy so you can see what rests on binding law versus commentary.
- 1FDA Cybersecurity Guidance (Sept 2023)Tier 2 VerifiedFDAfda.gov
- 2NIST SP 800-218 (SSDF)Tier 2 VerifiedNISTcsrc.nist.gov
- 3OWASP ASVS (project repository)Tier 4 UncheckedOWASPgithub.com
Inline markers like [1] jump to the matching reference above.