Notifications
Clear all
Topic starter
02/08/2026 9:43 am
TL;DR: Secure pull-request workflows for APIs still depend on running scans against realistic environments with dependencies in place, especially for microservice and gRPC-heavy systems, according to StackHawk. The governance lesson is that API security testing has to validate real execution paths, not just static code or isolated containers.
NHIMG editorial — based on content published by StackHawk: Love Your APIs: Secure Every Pull Request with StackHawk
Questions worth separating out
Q: How should security teams implement API security testing in CI/CD pipelines?
A: Start by automating the endpoints that carry privileged actions, sensitive data, or access decisions.
Q: Why do pipeline secrets create identity risk in shift-left testing?
A: Pipeline secrets are identity credentials, so they can be stolen, overused, or left exposed just like any other token.
Q: What breaks when API tests do not include microservice dependencies?
A: The test may pass even though the application fails when real services are present.
Practitioner guidance
- Instrument pull-request scans against full dependency stacks Run API security tests in environments that include the real services, databases, and authentication dependencies the application expects, rather than in a thin container that masks behaviour.
- Scope CI secrets to the narrowest test workflow Use short-lived credentials for scanners and supporting jobs, and separate the identity used for security testing from any identity that can modify infrastructure or access production data.
- Treat scanner access as a governed workload identity Assign ownership, rotation, and logging to the API key or token that authorises scan execution, especially when GitHub Actions or Kubernetes jobs can invoke it automatically.
What's in the full article
StackHawk's full post covers the operational detail this post intentionally leaves for the source:
- Concrete GitHub Actions configuration for running HawkScan as part of a pull-request workflow.
- Kubernetes pod and job examples for scanning multi-container application stacks.
- Custom authentication script handling for tests that need realistic login or token flows.
- Implementation detail on mounting config and scan assets into the container environment.
👉 Read StackHawk's guidance on securing API pull requests with runtime testing →
API pull request security: where shift-left testing still falls short?
Explore further
02/08/2026 12:36 pm
Shift-left security fails when the test environment is too small to represent the attack surface. The core problem is not the absence of scanning, but the absence of execution context. API behaviour, authentication checks, and backend trust relationships only reveal themselves when the scanner sees the full service graph. That is why dependency-aware validation matters more than a container that merely starts successfully. For practitioners, the governance question is whether the pipeline proves security under realistic conditions or only under simplified ones.
A question worth separating out:
Q: What is the difference between API testing and runtime API security?
A: API testing checks whether an endpoint meets design expectations before release. Runtime API security checks whether the live service continues to behave safely once it is exposed to real users, service identities, and production data. The difference matters because many API failures are not coding defects alone. They are behaviour and governance failures that only appear in operation.
👉 Read our full editorial: Secure pull requests for APIs need runtime testing, not assumptions
