Open source does not make software insecure. It makes the code visible to everyone. For a long time, the practical limit on turning that visibility into an attack was the cost of careful human investigation: understanding how a system works, tracing its assumptions and connecting a suspicious detail to a real way in.
That cost is falling. Modern AI makes it cheaper to conduct far more lines of investigation: following code paths, comparing versions, forming hypotheses and testing whether they hold.
At Strike, we apply the same shift defensively through continuous, deployment-aware review. AI helps trace relevant code, service boundaries and infrastructure definitions. Engineers validate credible claims and turn confirmed weaknesses into fixes.
The evidence standard
More investigation does not automatically mean more vulnerabilities. The same tools that make it easier to understand a system can produce a long list of things that look concerning when read in isolation.
A finding must explain who can trigger the behaviour, which protection or trust boundary fails, and what the attacker gains. Otherwise it remains a hypothesis.
The scarce resource is no longer finding possible problems. It is proving which ones are real.
Review the system, not a repository
That proof rarely lives in one source file. The relevant unit of review is the feature as it exists across the system: backend services that implement the behaviour, client code that exposes it, shared libraries and integrations that shape it, and infrastructure-as-code that determines how it is deployed and who can reach it.
A review traces a client action through the APIs and services behind it, then examines the callers, controls and deployment assumptions that govern the route. Infrastructure configuration is part of the evidence: it shows which identities are trusted, which routes are exposed and which controls apply. This is how a suspicious detail becomes either a credible path or a claim the team can reject.
Test identities and authority
An unauthenticated caller, an authenticated customer, a compromised employee identity and a compromised partner integration each present a distinct attacker model. Each has different access, assumptions to exploit and limits to test.
Looking at a feature through separate lenses like these moves the review beyond asking whether an endpoint exists. It asks whether the right person can access the right resource, whether a trusted identity has more authority than it should, and whether an external event is safe to act on. Important weaknesses often sit in the gaps between those boundaries.
For systems that move money, those questions carry particular weight. Rules that can sound like ordinary product logic are also security controls: who may initiate or approve a transfer, what limits apply, and whether a check happens as part of the action it is meant to protect.
Consider a balance check that happens separately from the transfer it authorises. If the state can change between the check and the transfer, the system may allow something it should not. The same is true when a production limit is disabled by configuration. These details determine who owns, controls or may move value.
Make review continuous
This kind of review cannot be a one-off audit that disappears into a calendar slot. It needs to return to the system regularly, choose a new domain, approach it through different attacker perspectives and retain what it has already examined.
The operating loop is straightforward:
- Select a bounded feature domain and map the code, integrations and deployment context around it.
- Test that domain through explicit attacker lenses and assemble evidence for any credible path.
- Have engineers independently validate the claim, then triage confirmed weaknesses into remediation.
- Turn validated paths into regression tests where appropriate, record the coverage, and move to the next domain.
AI widens the search and assembles context. Engineers decide what matters, validate the evidence and own the fixes. The result is a continuous, AI-driven security feedback loop that makes the system harder to break over time.
The goal is not to give an agent permission to attack live infrastructure. It is to let the agent reason deeply about the code and configuration that define the system, while live infrastructure remains outside its reach. Infrastructure expressed as code can show which routes exist, which identities are trusted and which systems can communicate without sending an automated tool to probe a production environment. The agent can inspect the blueprint rather than test the walls.
Pattern detection and system reasoning
None of this makes traditional security tooling obsolete. Static analysis continuously flags familiar risky patterns across a large codebase. It is good at asking whether a piece of code resembles a known problem.
The harder question is whether that apparent problem becomes an exploitable path in the system that actually runs. That requires following a feature through its callers, authority checks, integrations and deployment controls. Agentic review helps assemble that context and test the claim, while static analysis provides broad, repeatable coverage. The two approaches are complementary: one identifies known patterns; the other helps reason through how a system behaves in practice.
What continuous review changes
AI is forcing a harder conversation in open source. A dependency that has not received much expert attention was never truly safe. AI lowers the cost of investigating a latent mistake closely enough to form a credible exploit hypothesis. Maintained projects can use the same capability to revisit old assumptions, strengthen tests and turn new scrutiny into fixes. Projects under continuous examination are better placed to respond than those whose safety rests on untested assumptions.
External attackers can inspect public code and probe exposed surfaces. Inside Strike, we can also inspect the controls, configuration and service boundaries that determine whether a plausible path is actually reachable. That privileged visibility is valuable only when it is paired with active verification.
Security-first work is a recurring effort to test the assumptions that protect access, authority, integrations and the movement of money. At Strike, we use AI to widen and deepen that review, validate credible findings, fix confirmed weaknesses and keep looking. Each confirmed weakness becomes a fix and, where appropriate, a regression test. Each review adds to the evidence of what we have examined and where we need to look next.
