SAST examines source code and data flows for issues that developers can fix during development. Runtime defenses operate at a different control point.
Evaluation approach
If source analysis shows sensitive data flowing into logs, fix that flow first. Adding a protection SDK does not make inappropriate data handling safe.
Application example
Include the affected function, actual call path and production configuration in the finding. Retest the same flow in the corrected release.
Limits and considerations
A scanner that reports no findings does not establish that the code resists every form of attack.
Source findings and runtime events
A SAST finding identifies a code path that needs attention. A RASP event reports a condition observed at a particular moment. Linking both records to the same application version makes it easier to investigate a weakness in the field.
Even when RASP temporarily limits a defect's impact, retain the code fix's owner and due date. Otherwise, a temporary control can become permanent technical debt. Once the next release contains the fix, revisit both source analysis and the relevant runtime test.
Checks and decisions
- Assign owners to findings
- Track code remediation
- Test the distributed package separately
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.