Combine static and dynamic tests around a verified finding

Static analysis examines code or build artifacts without exercising a particular live request. It can identify a flow from request input to a dangerous sink even when a route is hard to reach. Dynamic testing exercises a running system and observes behavior under a particular identity, configuration and data state. Interactive testing (IAST) places an agent inside the running application during functional or dynamic tests and reports the code path each request took; it adds execution context but still sees only the behavior those tests exercised. A clean static report may reflect a missing rule or unsupported framework; a clean dynamic scan may mean the scanner never authenticated or reached the feature.

Use an invoice lookup that interpolates an owner parameter into SQL. A static finding names source request.query.owner, an intermediate helper and sink database.execute. A dynamic probe can show whether the query actually returns foreign rows. The strongest result connects the two: an identified code path, a controlled request that reaches it, observed impact and a regression after the repair. Neither tool alone knows every business authorization rule or deployment assumption.

This guide works one finding through both techniques. To choose tools for a category in the first place, including IAST, SCA, secrets, IaC, container and API scanners, see /domains/appsec/testing/appsec-tool-categories-and-evaluation/.

Record source revision, analyzer version, rule id, relevant configuration and the source-to-sink path. Review transformations along that path. An apparent sanitizer may remove quotes but leave another grammar problem; an actual parameter-binding API may break the injection flow. Do not suppress a finding solely because a test payload failed once. State the reason the sink is safe or the path is unreachable, with supporting code and conditions.

For the fixture, the vulnerable query places owner inside a quoted SQL literal. The supplied probe closes the literal and introduces a true predicate. Replacing interpolation with a bound parameter fixes grammar separation; /fix/sql-injection/ shows that repair for each common stack. Adding an authentication check alone does not: a legitimate member may still supply the probe. Similarly, suppressing the rule or renaming the helper changes the report without changing the program's behavior. A useful static regression verifies the dangerous path is gone, while a behavioral test verifies the required lookup still works.

Project rules make the static claim precise. The Semgrep rule below uses taint mode: request values are sources, the SQL text argument of execute is the sink, and a value passed in the separate parameter tuple never reaches it. Keep each rule beside a test file whose lines are annotated # ruleid: where it must fire and # ok: where it must not; with Semgrep 1.180.0, semgrep --test passed for string concatenation and an f-string, stayed silent for the bound query, and a scan of the exercise handler produced one SARIF result at the concatenating line. CodeQL offers the same source-to-sink model through its query packs and GitHub default setup.

rules:
  - id: python-sql-built-from-request
    mode: taint
    languages: [python]
    severity: ERROR
    message: >-
      Request data reaches SQL text. Pass it as a bound parameter instead,
      for example execute("... WHERE owner = ?", (owner,)).
    metadata:
      cwe: "CWE-89: Improper Neutralization of Special Elements used in an SQL Command"
    pattern-sources:
      - pattern: request.args.get(...)
      - pattern: request.args[...]
    pattern-sinks:
      - patterns:
          - pattern-inside: $DB.execute($SQL, ...)
          - focus-metavariable: $SQL

Run the rules on every pull request so a finding reaches the author while the change is fresh, and publish results in SARIF, the format GitHub code scanning and most security platforms import. The workflow below tests the rules first, so a broken rule cannot silently report nothing, then scans and uploads the SARIF even when the scan fails. It grants only the permissions the upload needs, pins actions to commit SHAs and keeps the checkout token out of the workspace; actionlint 1.7.12 and zizmor 1.30.1 reported no problems with it. For an existing codebase, start from a baseline so only new findings block the merge, and record each dismissal with its reason rather than excluding files.

# .github/workflows/sast.yml: project Semgrep rules on every pull request, results as SARIF.
name: sast
on:
  pull_request:
  push:
    branches: [main]
permissions: {}
jobs:
  semgrep:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write # upload-sarif creates code scanning alerts
    container:
      image: semgrep/semgrep:1.180.0
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - name: Check each rule against its annotated test file
        run: semgrep --test semgrep-rules/
      - name: Scan the repository
        run: semgrep scan --config semgrep-rules/ --exclude semgrep-rules --sarif --output semgrep.sarif --error
      - name: Upload results to code scanning
        if: always()
        uses: github/codeql-action/upload-sarif@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4.38.1
        with:
          sarif_file: semgrep.sarif
          category: semgrep

Before interpreting an attack result, establish a normal request that succeeds as the intended synthetic actor. Record status, route marker or correlated server trace, and expected data. Then change only the test value. A scanner receiving a login page with status 200 has not tested the invoice handler. A reverse proxy blocking all unusual strings may prevent the probe without fixing the vulnerable backend, leaving alternative encodings or internal callers exposed.

Use a controlled test environment and synthetic records, and keep the payload's effect bounded to observation. Compare the authorized baseline with an injection value and a quote-containing ordinary name. Inspect returned row ids, not only status. Dynamic evidence is scoped to the tested deployment digest, route, credentials, input and time. Expired sessions, missing feature flags and stale deployments can all make a post-fix run appear clean for the wrong reason.

The ZAP Automation Framework plan below scans a test deployment as a dedicated user. The context's authentication block logs in with a form, verification polls a protected URL and checks for text only a signed-in response contains, and a requestor job confirms the protected handler returns 200 before the spider and active scan start. Against a local training copy of the exercise's vulnerable handler, ZAP 2.17.0 reported SQL injection (rule 40018) on /accounts?owner=; the same plan without the user finished with "Automation plan succeeded!" and no alerts, because every request was redirected to the login page.

# zap.yaml: ZAP Automation Framework plan for an authenticated scan of a test environment.
env:
  contexts:
    - name: accounts
      urls: ["http://app:8090/"]
      includePaths: ["http://app:8090/.*"]
      excludePaths: ["http://app:8090/logout.*"]
      authentication:
        method: form
        parameters:
          loginPageUrl: "http://app:8090/login"
          loginRequestUrl: "http://app:8090/login"
          loginRequestBody: "user={%username%}&password={%password%}"
        verification:
          method: poll
          loggedInRegex: "\\Q\"owner\": \"alice\"\\E"
          loggedOutRegex: "\\QLocation: /login\\E"
          pollFrequency: 20
          pollUnits: requests
          pollUrl: "http://app:8090/accounts?owner=alice"
      sessionManagement:
        method: cookie
      users:
        - name: alice
          credentials:
            username: alice
            password: ${ZAP_ALICE_PASSWORD}
  parameters:
    failOnError: true
    progressToStdout: true
jobs:
  - type: requestor  # a known authenticated request, so the scan starts from the real handler
    parameters:
      user: alice
    requests:
      - url: "http://app:8090/accounts?owner=alice"
        responseCode: 200
  - type: spider
    parameters:
      context: accounts
      user: alice
      maxDuration: 1
  - type: activeScan
    parameters:
      context: accounts
      user: alice
      maxScanDurationInMins: 5
    policyDefinition:
      defaultStrength: low
      defaultThreshold: "off"
      rules:
        - id: 40018  # SQL injection
          strength: medium
          threshold: low
  - type: report
    parameters:
      template: traditional-json
      reportDir: /zap/wrk
      reportFile: zap-report

The closure record should say which source change removes the unsafe interpretation, which candidate artifact contains it and what the paired tests observed. Re-run the original reproducer against the candidate and retain a normal case. If the analyzer still reports a safe binding API, document that specific false positive with narrow suppression and a regression; do not disable an entire rule category across the repository.

Use disagreement as a diagnostic clue. Static positive/dynamic negative asks whether the path is reachable and whether the test got past authentication. Static negative/dynamic positive asks whether the analyzer modeled the framework and sink correctly. Both negative is only scoped evidence, not proof of absence. Keep scanner credentials restricted, reset test data and avoid putting session tokens or captured private responses into broadly accessible build logs.

Suppose the source analysis runs on commit C2 but the dynamic environment still serves C1. A clean static report and a successful dynamic exploit are not contradictory; they concern different programs. Record the deployed artifact digest or equivalent revision alongside test traces. A page footer is a useful hint but can be cached or changed independently; prefer evidence from the deployment system and a correlated application request.

Coverage also depends on identity and state. A scanner with an ordinary member account cannot exercise administrator-only routes, and an expired session may redirect every request halfway through a run. Include a periodic authenticated baseline and stop interpreting later negative results when it fails. Reset synthetic data so a previous request does not remove the resource needed by the next test. A scanner cannot assess an operation it never successfully reaches.

For static analysis, a new framework wrapper can hide a known sink from the analyzer. Compare the modeled call path with the actual wrapper behavior rather than assuming a tool upgrade understands every project helper. Narrow custom modeling may be appropriate, but it should be reviewed and exercised by a representative known-positive and known-safe case. The aim is reliable evidence about specific paths, not maximizing alert volume or minimizing it through broad exclusions. This also makes trend metrics meaningful: fewer alerts after excluding half the repository is a scope change, not necessarily a security improvement.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Semgrep: test rules
2. Semgrep: taint analysis overview
3. GitHub: uploading a SARIF file to code scanning
4. ZAP Automation Framework: authentication
5. OWASP WSTG-INPV-05: testing for SQL injection. WSTG v4.2.
6. CodeQL: about data flow analysis
7. Semgrep: ignore files, folders and code

Reference information

Tags

Security testingVulnerability management

SDLC phase

TestingMaintenance

Role

DevelopersAppSec engineers

Download this guide as Markdown

Continue exploring