Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A scanner warning disappears after a refactor, but the application still builds a database query from untrusted input. A useful remediation test protects the security property behind the finding rather than simply asserting that the scanner no longer reports it.
Use a fictional support-search endpoint that accepts a customer-supplied search term. Static analysis reports a path from the request parameter to dynamically assembled SQL. The engineering task is to understand that path, repair the query construction and preserve legitimate search behaviour with tests another maintainer can understand.
SAST remediation starts with the reported data flow
Read the source location, intermediate transformations and final operation identified by the finding. Confirm which input an external caller can influence and what privileges the affected code executes with. A report is a lead to investigate, not a substitute for establishing how the application handles the value.
Trace the support endpoint through its validation layer, service function and database adapter. Record where the query’s structure is assembled and where values are supplied. If the finding depends on configuration, identify the relevant mode and test it explicitly instead of assuming the development defaults match production.
Write the intended property in plain language before changing code. In this example, user-controlled search text must remain a bound value and must not alter SQL structure. That statement tells a reviewer what the fix needs to preserve even if the implementation later moves to a different helper.
Choose the narrowest test that observes the property
A unit test can inspect the boundary between the query builder and database adapter. It should verify that the query structure remains fixed for the relevant input and that the value is supplied through the adapter’s supported parameter mechanism. Avoid asserting every incidental formatting detail if it has no bearing on that property.
An integration test can then verify behaviour with the actual database driver and a controlled fixture. This catches mistakes hidden by a permissive mock, such as using a placeholder form the driver does not support. Keep the fixture isolated and synthetic so the test can run without touching real customer records.
Neither layer alone answers every question. The unit test makes the construction rule clear, while the integration test checks the application’s real execution path. Use the smallest combination that demonstrates the failure and protects the correction without turning a local fix into a broad test-suite rewrite.
SAST remediation tests need valid inputs as well
Build a small input matrix before implementing the correction. Include ordinary text, an empty value if supported, punctuation used in real names and a bounded adversarial string chosen for the controlled fixture. The assertion should describe the expected behaviour, not merely require an exception for anything unfamiliar.
| Input class | Expected behaviour | Regression it can expose |
|---|---|---|
| Ordinary search text | Returns only intended fixture matches | Broken normal workflow |
| Legitimate punctuation | Treated as data | Overly restrictive filtering |
| Adversarial syntax | Cannot change query structure | Unsafe string construction |
| Unsupported length | Documented validation outcome | Missing input bounds |
| Empty input | Explicit product behaviour | Accidental broad query |
Do not make removal of punctuation the primary injection defence. Parameterised queries separate data values from query structure; rejecting normal customer text can hide the original bug while degrading the product. Where an identifier such as a sort column cannot be supplied as a bound value, map an allowed option to a fixed identifier through a separate reviewed path.
Prove the test fails for the original defect
Run the focused regression against the vulnerable implementation in the isolated development environment. Confirm that it fails for the intended reason. A test that is already green may be exercising another route, using a mock that discards the dangerous input, or asserting a result unrelated to the finding.
For the support-search example, inspect the adapter call and the fixture result rather than trusting the test name. The failure should demonstrate that untrusted text influences query structure or violates the intended result boundary. If reproduction depends on a missing condition, document that condition before deciding whether the report is valid.
After the correction, rerun the same test without weakening its assertion. Keep the original failing observation in the review record. That before-and-after evidence is more useful than a new test added only after the implementation was changed to satisfy it.
Repair the dangerous operation at its responsible layer
Prefer a correction where the unsafe query construction occurs. Repeating filters at several callers can leave another route vulnerable and make maintenance harder. At the same time, avoid a speculative rewrite of every database access path when one shared helper can enforce the intended property.
Check all callers of the changed helper and its contract. A function that previously accepted a complete SQL fragment cannot silently start interpreting that argument as a search value without reviewing its callers. Preserve intended behaviour or make the contract change explicit in the patch and tests.
Retain application-level authorisation checks. Parameterising the query prevents one class of injection; it does not establish that the requester may view every row the query returns. The security test should not become an excuse to remove the tenant or ownership restriction surrounding the operation.
Verify the release, not only the source patch
Run the relevant static analysis again on the corrected revision and inspect the new result. A disappeared warning is supporting evidence, especially when the rule still analyses the path. Check that the file was not accidentally excluded or made unreachable to the analyser through a configuration change.
Then connect the correction to the built artefact and deployed workload where applicable. The repository can contain the safe implementation while an older image remains active. Treat deployment verification as a separate completion condition rather than claiming that a merged patch resolved every affected environment.
Keep the final handoff concise: finding reference, root cause, changed boundary, regression test, tested revision and outstanding deployment scope. Another engineer should be able to understand why the correction works without reading the entire investigation history. This is also the record that makes a future refactor safer.
Key takeaways
- Express the security property behind the SAST finding before writing the correction.
- Test dangerous inputs and legitimate behaviour at the responsible boundary.
- Demonstrate that the regression fails for the original defect and passes after the fix.
- Combine rescan evidence with verification that the corrected artefact reached the affected environment.
How SecurityVault approaches this
SecurityVault’s SAST workflow provides source-analysis findings with the evidence needed to investigate the relevant path. Per-language analysis and connected repository context help the receiving engineer locate the code under review. The useful handoff explains the suspected source-to-operation relationship rather than presenting a severity label alone.
The engineer still has to validate the finding, choose the correction and write a meaningful regression. A scanner result does not automatically establish the application’s full threat model, and a later clean result should be considered alongside the test and the analysed revision. Human disposition remains part of the decision record.
The platform workflow connects source findings with build, image and workload context so teams can follow the correction beyond the commit. During an evaluation, bring a small authorised test repository with a known defect and a repaired revision. To agree the evidence expected from that walkthrough, request a demonstration.