Turn on CodeQL, Dependabot, and Secret Scanning across a handful of repositories and you get exactly what the marketing promised: findings. Lots of them. Each one sitting in its own repository's Security tab, behind its own set of tabs and filters, with no shared notion of who owns this, when is it due, or are we getting better or worse.
That's the gap. GitHub is genuinely world-class at the detection half of application security. The operational half - triage, deadlines, ownership, trend lines, and the evidence trail an auditor asks for - is left as an exercise for the reader. Most teams solve it with a spreadsheet, a recurring calendar reminder, and a security engineer who clicks through fifteen repos every Monday morning.
Yōkai is that missing half. It's a free security operations layer that sits on top of GitHub's scanners and turns raw alerts into a managed workflow.
The actual problem
Whether you're maintaining a handful of side projects or running AppSec for a company, this list will look familiar:
- Alerts live per-repository. There is no single queue. Fifteen repos means fifteen Security tabs and no way to ask "show me every open critical, sorted by how overdue it is."
- Nothing has a deadline. A critical SQL injection alert and a low-severity code smell look identical in the UI six weeks later. Severity is not the same thing as urgency.
- No trend. You cannot easily answer "did we get better this quarter?" or "how long does it actually take us to fix a high?" The data exists, but not in a form you can put on a slide.
- Scanners are siloed. CodeQL findings, Dependabot alerts, and leaked secrets are three separate mental models in three separate places.
- Evidence is manual. When someone asks for proof that every critical was patched inside the window, you go spelunking through alert histories by hand.
None of these are detection problems. They're all management problems, and they're the reason security programs need headcount that scales linearly with repository count.
What Yōkai actually does
Yōkai installs as a read-only GitHub App. It pulls alert metadata from the three GitHub Advanced Security scanners and gives you the layer on top:
One dashboard across every connected repository. A Security Health score (0–100), open findings with the critical count called out, SLA compliance percentage, and mean time to resolve - each with an eight-week sparkline so you can see the direction, not just the number. The health math is deliberately blunt: start at 100, subtract 15 per open critical, 5 per high, 2 per medium, 1 per low. A repo drowning in criticals scores 0, and it should.
A real triage queue. Every finding from every repo in one filterable, searchable list - by severity, status, rule, CWE, or file path. Each finding tracks a lifecycle: Open → Resolved | Ignored | Removed. Expand one and you get the description, the exact file and line, a remediation hint, and a jump link to the native alert on GitHub.
SLA deadlines per severity. Every finding gets a resolution deadline counted from when GitHub first raised the alert. The free tier ships with sane defaults:
| Severity | Deadline |
|---|---|
| Critical | 3 days |
| High | 14 days |
| Medium | 30 days |
| Low | 90 days |
A background job re-evaluates SLA status every 15 minutes and flags breaches. Findings approaching their deadline float to the top of the dashboard's Actionable Alerts panel - so the thing you see first is the thing that's about to be late, not the thing that happened to be found most recently. Dismissed and removed findings are excluded from the math, so your compliance rate isn't polluted by alerts nobody needs to act on.
Analytics that answer the quarterly questions. Severity breakdown, opened-vs-resolved per week over the trailing eight weeks, per-scanner resolution times, per-repository risk ranking, and SLA compliance by severity.
An append-only audit log. Every sync, every new finding, every status change, with the acting user and a timestamp. Events are only ever inserted - never updated, never deleted.
One design decision worth calling out
GitHub stays the source of truth. Yōkai reports on your alerts and tracks them against your policies; it never mutates them. You resolve or dismiss an alert on GitHub, and Yōkai reflects the new status on the next webhook or sync. That's a deliberate constraint - two systems that can both write the same state will eventually disagree, and when they do, you no longer trust either one.
The syncing is layered so nothing goes missing: an initial sync on install, real-time webhooks for updates within seconds, an hourly full reconcile as a safety net, and a Sync Now button when you're impatient.
What it stores
Alert metadata only - rule names, descriptions, severities, file paths, line numbers, repository names. Yōkai never clones or stores your source code, and the GitHub App holds read-only permissions on security alerts and metadata. It can't push code or change repository settings. Access mirrors GitHub's own rules: you only see organizations you belong to, and membership is re-checked at every sign-in, so losing access on GitHub removes it here too.
One more thing worth knowing: installing the App alone doesn't start anything. Yōkai only syncs an organization once a member of it has signed in, so alerts are never pulled for people who haven't opted in.
Trying it out
The Community tier is free - no credit card, no trial clock. Here's the whole setup:
1. Sign in with GitHub at yokai.n1netails.com. OAuth only; there's no separate password to create.
2. Install the Yōkai GitHub App on your organization. Choose "Only select repositories" and pick up to 5, or "All repositories" if your org has 5 or fewer. The installation webhook kicks off an immediate sync of every existing alert.
3. Wait about a minute. Alerts land on your dashboard.
That's it. Realistically the only thing that trips people up is step zero:
Yōkai syncs alerts - it doesn't run scans. Each repository needs GitHub's scanners actually enabled, or there's nothing to sync. In each repo:
Settings → Advanced Security→ turn on Code scanning (CodeQL default setup), Dependabot alerts, and Secret scanning. All three are free for public repositories.
If you forked something specifically to test this, note that GitHub disables Dependabot alerts and code scanning on forks by default - you'll need to switch them on in the fork's own settings.
What's in the free tier
- Up to 5 repositories in one GitHub organization
- GitHub App integration with real-time webhooks and hourly sync
- CodeQL, Dependabot, and Secret Scanning alert sync
- Security dashboard with live metrics and trends
- Finding triage with lifecycle tracking
- SLA tracking with default policies
- Security analytics and reports
- Full audit log
- Email support
Custom SLA policies, unlimited repositories, and team integrations (Slack, Jira, Teams) are planned for the paid tiers, which are still in development. The pricing page lets you register interest if that's the shape you need.
Who this is for
If you're a solo developer, five repositories is the whole free tier and you can connect them in the time it takes coffee to brew. You get the thing that's genuinely hard to maintain alone: a single list of what's open across all your projects, with the overdue items floated to the top, so security work stops being a background guilt and becomes a short queue you can actually clear. Side projects are exactly where alerts pile up unread - nobody's nagging you about the dependency advisory on the repo you last touched in March.
It's also the cheapest way to find out whether the model fits how you think. Poke at it on your own repos, and if it clicks, you already know what you'd be proposing when the topic comes up at work.
If you're on a team, the pain is sharper and the same tool answers it: a shared triage queue instead of fifteen Security tabs, deadlines that make "critical" mean something operationally, and an audit trail for the moment someone asks you to prove criticals get fixed on time.
Either way the first run tells you something concrete: how many open findings you actually have, how many are already past a reasonable deadline, and whether the trend is going the right way.
Kick the tyres at yokai.n1netails.com. The docs cover setup and troubleshooting in more detail, and support@n1netails.com goes to a human if you get stuck.
Top comments (0)