Inspiration
When a security scanner flags a file, the developer still has to answer three questions: Where is the evidence? How confident should I be? What should I change? We built Sentinel to bring those answers together, starting with a map of the codebase developers can explore.
What it does
Sentinel maps a repository and flags files that may contain security weaknesses. For each candidate, it connects the relevant source evidence to a MITRE CWE classification, an AI review, and a proposed fix and regression test.
In the demo, judges can replay the scan, search by file or CWE, and click a file to pin its findings while exploring the graph. They can also turn a finding’s defensive guidance into a draft lesson for ChatOverflow.
How we built it
We built the analysis pipeline in Python. The first stage maps repository files without executing the target code. Module I combines language-specific static rules, MITRE CWE definitions, and an AI discovery pass to surface candidates with line-level evidence. Module II reviews that evidence and records a verdict for each candidate. We built the demo in HTML and JavaScript so judges can explore the saved scan directly in a browser.
Challenges we ran into
Our early scans surfaced only a few benchmark matches. crAPI spans multiple languages, and rules that worked in one service missed patterns in another. Adding language-specific rules and filtering test and empty files helped us surface more useful candidates. The harder problem was verification. A relevant line can point to a weakness, while the code around it determines whether the evidence supports the claim.
Accomplishments that we're proud of
On OWASP crAPI, Sentinel’s final scan surfaced 50 candidates and matched 18 of 18 documented benchmark challenges by file and CWE. Module II reviewed all 50 candidates. It confirmed 1, found 7 strongly supported, refuted 4, and left 38 inconclusive.
We also turned that scan into an interactive demo where judges can follow a finding from the repository map to the proposed fix. Sentinel source and demo files
What we learned
Discovery and verification need different measures of success. Broad discovery helps surface issues worth investigating. Verification needs enough evidence to justify the verdict. Keeping those stages separate let us show where Sentinel found a useful lead and where a developer would still need more context.
What's next for Sentinel
We want to test Sentinel on repositories outside crAPI to see which rules generalize. We’ll also work on pulling in more context across files to resolve inconclusive reviews. From there, we want to bring the evidence and proposed fixes into pull requests, where maintainers can review them alongside the code they’re already working on.
