Build vs. Buy: SAST Assessment Recommendation
—
—
Buy pressure
This is the minority result. You have named owners past year one, you can measure whether a change helped, and part of your stack has no vendor coverage at any price.
Build doesn't mean build everything. Use off-the-shelf engines where they are good, and spend your engineering on the internal frameworks nobody outside your company has heard of.
The failure mode isn't the build. It's year two, when the benchmark set decays and the maintainer moves teams. The checklist below exists to make that visible early.
What to do next
- Write the benchmark set before the scanner A few hundred labeled findings per language, from your own repos, re-scored on every change. Without it nobody can verify an accuracy claim, including the engineer who wrote the tool.
- Fingerprint findings on structure, not location Suppressions must survive a refactor and a model swap. Keep the decision ledger in your own storage.
- Cap the inference spend before finance asks Monthly caps per repo and per org, a token ceiling per PR, and a fallback to the cheap model above a diff-size threshold.
- Name the year-three owner in writing Maintenance belongs in a job description, not a 20% allocation.
- Start advisory, earn the merge gate Do not gate CI until reruns on the same commit agree and your false positive rate has held for a quarter.
- Re-run this when your stack changes A new acquisition, a new runtime, or a maintainer leaving all change the answer.
Detection is close to a commodity. Semgrep, CodeQL, and the language-specific analyzers will find things in your code this week.
The expensive part is everything after: deciding which findings are real, keeping that decision stable across refactors and model versions, and producing a fix a developer will merge. That's where internal projects stall.
Keep your engineers on the rules that encode your own frameworks. Buy the layer where accuracy has to be measured against somebody else’s benchmark rather than your own good intentions.
What to do next
- Keep your rules, rent the verdict Your custom rules encode knowledge nobody outside your company has. Keep writing them. Do not also write the triage engine.
- Insist on a portable decision ledger Suppressions should be exportable and fingerprinted independently of the engine.
- Benchmark the vendor on your code, not their demo The benchmark is the asset. The engine is replaceable.
- Price both halves before you commit A hybrid still carries the maintenance and inference cost of the half you keep.
This is the modal result, and it’s the honest one. The gap between getting findings out of an open-source engine and running a security control the board hears about is a product.
The failure sequence is in the findings below: the benchmark set never gets written, suppressions evaporate on the first refactor, developers stop trusting the tool, and somebody quietly stops looking at the dashboard.
Buying doesn't remove the work. It moves it from maintaining an engine to integrating one, which is smaller and more predictable.
What to do next
- Still build the benchmark set A few hundred labeled findings from your own repos is how you evaluate vendors and stay able to leave. It's the one artifact worth building either way.
- Make the exit cheap in the contract Exportable findings, exportable suppressions, stable fingerprints. If leaving means re-triaging everything, you haven't bought a tool, you've bought a dependency.
- Ask how accuracy is measured, not what it is Any vendor can quote a false positive rate. Ask which labeled corpus produced it.
- Start advisory, then gate Do not put a new scanner in the merge path on day one, vendor or not.
Question by question
Your answer, then what it means. These notes are the same for every reader.
Q1. Who owns this scanner in year three?
Your answer — —
Ownership is the line item nobody puts in the estimate
One owner is a single-person dependency on a control you report to the board. When that person leaves the tool doesn't fail loudly, it just stops keeping up with new frameworks.
Budget the maintainer, not the builder. The build has an end date. The maintenance doesn't.
Q2. How many languages are in active production?
Your answer — —
Language count multiplies every other cost here
Tuning Python to a 15% false positive rate teaches you nothing about your Go services. Each language needs its own parser, rules, and accuracy measurement.
If part of your stack is internal or proprietary, no vendor supports it and building is right for that part. It's the one case where we'll tell you to build.
Q3. Your team says the scanner got more accurate. How do you verify that?
Your answer — —
You can see your false positives. You cannot see your misses.
Fewer findings isn't better, it's just fewer. A change that cuts noise 30% while dropping two real injection flaws looks identical to a genuine improvement.
Developers complain about wrong findings, so noise gets fixed. Nothing complains about a vulnerability that was never surfaced.
The fix is a benchmark set: a few hundred findings per language from your own repos, labeled once by a human, re-scored on every change. Budget a few weeks of senior AppSec time per language, and expect it to decay as the code changes.
Q4. You change the model. What happens to the 400 findings your team already dismissed?
Your answer — —
Most internal scanners die of attrition, not accuracy
Line-number suppressions die on the first refactor. A formatter reflows the file and every dismissed finding returns as new, so developers stop trusting the tool.
Risk acceptance is a compliance artifact, not a UI state. It has to outlive the model version that produced the finding.
Nondeterminism is fine in a dashboard and disqualifying in a merge gate. If a rerun can flip a result, you cannot block a release on it.
Q5. Can you predict next quarter's inference bill within 20%?
Your answer — —
A license line and an unbounded cloud spend are different animals
A 4,000-line PR can cost fifty times a typo fix. Monorepo full scans are another order of magnitude, and retries multiply it again.
Model deprecation is a forced migration on the provider’s schedule, and every migration invalidates the benchmark set from question three.
Finance treats a license line and a developer-triggered cloud spend differently. That distinction isn't technical, but it's what kills the project in month nine.
Q6. Where do findings have to appear before developers fix them?
Your answer — —
Gate CI and you're running production infrastructure
Someone owns the pager when the scanner is down and the release train is stopped at 2am. That's an on-call rotation and a rollback path, for a tool the security team wrote.
Q7. Should the tool find the vulnerability, or close it?
Your answer — —
Finding is a weekend. Closing is a product.
Semgrep, CodeQL, and a dozen open-source parsers will get you findings by Friday.
Closing is different work. A wrong finding wastes an hour of a developer’s time; a wrong fix ships, and the accuracy bar is an order of magnitude higher.
Build in-house or license Corgea
Compare your internal engineering and model costs with Corgea's per-developer license.
Build in-house vs. buy Corgea
These are different cost models
The in-house estimate includes your engineering, infrastructure, and model API spend. Corgea is a software license per developer. The model costs below apply only to the in-house build.
— in year one · — per year after
Engineering + infrastructure + model APIs— per year for —
$39/dev with monthly billing · 5-seat minimum— per year for —
$49/dev with monthly billing · 20-seat minimumIn-house cost breakdown
—
—
—
—
—
—
In-house model API cost
Same workload, 9 models. Pick one to fold into the totals. List prices as of September 2026.
—
What this model deliberately leaves out
- The cost of a miss. A vulnerability that was never surfaced appears on no invoice.
- Forced migrations. Model deprecation runs on the provider's schedule, and invalidates your benchmark.
- On-call. A scanner in the merge path needs a pager. That's a rotation, not a line item.
- Variance. A 4,000-line pull request can cost fifty times a typo fix. These are averages.
Assumptions and sources
- Corgea license pricing
- Public list prices, September 2026. Growth: $31/dev billed yearly or $39 monthly, 5-seat minimum. Scale: $39/dev billed yearly or $49 monthly, 20-seat minimum.
- Model pricing
- OpenAI and Anthropic list prices, September 2026. Cache reads are 10% of base input, except Claude Fable 5.1 and Mythos 5.1 at 2.5%. Cache writes are not modeled, so cached figures run slightly optimistic.
- Pull requests per developer per week
- Default 1.7. Benchmarks across roughly 8 million pull requests put merge frequency above 2.0 for elite teams and 1.2–2.0 for the band below.
- Tokens per scanned pull request
- Published per-PR review workloads cluster at 8k input / 1k output for diff-only, 25k / 1.5k with file context and a triage pass, and 80k / 4k for cross-file changes with patches.
- Scans per pull request
- Default 1.6, covering the scan on open plus review pushes. Raise it well above 2 if you scan every commit.
- Full-repository baseline scans
- 1.2M input and 60k output tokens per repository per scan. Monorepos run an order of magnitude above that, which is the variance finance objects to.
- Fully loaded engineer cost
- Default $210,000 a year for a senior security engineer, including taxes, benefits, and equipment. Adjust to your market.
If you would rather not build it
Corgea finds it, writes the fix, and opens the pull request
Refactor-proof fingerprints and a fixed line in the budget, not a per-token bill.
We sell a SAST product, and this assessment just told you not to buy it. That's the correct answer for your situation, so it's the answer you get.