Secure your Semgrep surface
Static analysis findings tied to code owners, with rules tuned to your codebase rather than a generic ruleset. We don’t connect to Semgrep to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Semgrep goes wrong
Semgrep goes wrong when it is noisy: a scanner producing false positives trains engineers to dismiss findings, including the real ones.
- Default rulesets producing noise that trains engineers to ignore findings
- Scans running only on pull requests, missing what is already in main
- Findings without an owner, accumulating indefinitely
- Custom rules absent, so patterns specific to your codebase go undetected
- CI integration failing open, reporting success when the scan did not run
[02] What We Secure
What we watch, catch and fix on Semgrep
On Semgrep we tune rules to your stack and write custom detections for your own known-bad patterns.
- Rule tuning to your stack, because a noisy scanner is functionally a disabled one
- Baseline scanning of existing code alongside new changes
- Findings routed to code owners with real remediation deadlines
- Custom rules written for your own known-bad patterns
- CI failure modes checked so a broken scan is visible rather than green
[03] Where It Lands
Where Semgrep lands in your registers
Repositories and pipelines become asset register entries with their own criticality, because a build system that can deploy to production is a production system. Access reviews cover repository and pipeline permissions alongside your other entitlements, and the risk register carries supply chain exposure — the dependencies you pull, the actions you run, and who can push without review.
[04] How We Engage
On Semgrep specifically
On Semgrep, we tune rules, write custom detections for your patterns, and triage findings to owners. Remediation of systemic patterns across the codebase we scope as a project with your engineering leads.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Semgrep FAQs
What Semgrep access does Konfirmity need?
Konfirmity needs an API token with read access to deployments, projects and findings. Where you want us to maintain your rule set, we work through your repository rather than requiring write access to your Semgrep configuration.
Do you write custom rules for our codebase?
Yes, and it is usually where the value is. Generic rulesets catch generic problems; your codebase has its own patterns — an internal auth helper used incorrectly, a sink that must never take user input. We write rules for those and maintain them as the code evolves.
GitHub
GitLab
Bitbucket
Jenkins
CircleCI