Job security-alerts-triaged-with-reachability-evidence · revised 12 October 2026
Find out which of your Dependabot alerts actually matter, with evidence you can re-run
Each open alert at or above your severity gets a decision: a fix pull request, a dismissal backed by evidence you can re-run, or needs an owner. We dismiss nothing and give no assurance.
You might be seeing
- Alerts say a vulnerable package is present, not whether your code calls the vulnerable part
- The alert list grows because dismissing needs a reason nobody has time to prove
No passwords, keys, card details or admin invites needed to start.
What usually happened
Dependency alerts report that a vulnerable package is present, not whether your code reaches the affected function. Dismissing one needs a reason, and an unproven dismissal is a risk. Reachability tools exist for some languages, but nobody has run them and written down the result.
Who it’s for: A lead facing a long alert list, a customer security questionnaire or an audit, who cannot tell which alerts need action.
Usually starts when: There are 60 or more open dependency alerts, someone has asked which matter, and nobody has had time to check.
The result: Each open alert at or above the agreed severity gets one decision: a fix pull request for those that are patchable, a proposed dismissal backed by commands and output you can re-run, or needs an owner. A list shows what could not be determined. We dismiss nothing on the platform, and this is evidence, not assurance.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- The decision table
- The re-runnable evidence for each proposed dismissal
- Up to 5 fix pull requests
- The could-not-decide list
Included
- One repository in an ecosystem with a usable reachability tool, and up to 60 open alerts at or above an agreed severity
- A decision table with one row per alert
- For each proposed dismissal, the commands and output from a named tool that you can re-run
- Up to 5 fix pull requests for patchable alerts, on a branch you merge
- A list of alerts we could not decide, with the reason
Not included
- Dismissing, snoozing or closing any alert on the platform
- Assurance, certification, an audit opinion or a statement that your software is secure
- Investigating a suspected compromise: use your incident process
- Reachability claims that come from a model's opinion rather than a tool's output
- Secret-scanning and code-scanning alerts; those are a separate service
- Alerts that need private registry credentials
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every in-scope alert has exactly one decision (fix, proposed dismissal, needs owner or could not decide), checked by script against the alert export.
Evidence: The script count of alerts against rows in the table.
Your engineer re-runs the stored commands for 10 sampled proposed dismissals, gets the same output, and for each opens the code the tool reports on and finds none that is in fact reachable. A reachable one marked not reachable fails the whole test. It describes the ten sampled.
Evidence: The 10 sampled rows, the commands, outputs and your engineer's verdicts. This describes the ten sampled, not every dismissal.
Each proposed dismissal cites a named tool with its version and a command that produces the evidence, not a model's opinion.
Evidence: The evidence column and a script check for an empty command.
Nothing was dismissed, snoozed or closed on the platform by us.
Evidence: Your repository security log for the period.
Sign-off. Your engineer reads the table and the sample re-check and signs off in writing. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- An ecosystem with a usable reachability tool, named in the agreement
- Read access to the alerts through a Read-only account or an export
- Tests that run in CI
- A named engineer who re-checks 10 sampled dismissals
We stop and tell you if
- Any sign of compromise: you follow your incident process and we stop
- No reachability tool exists for the language, so most alerts could not be decided
- Alerts depend on private registries that need credentials
What could go wrong
Fix pull requests can be closed or reverted. We dismiss nothing on the platform, so alerts stay open until your people decide. Our copies of your code are deleted when the job ends.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A dismissal is wrong and a real weakness stays open. | Proposed dismissals rest on tool output you can re-run, zero wrong "not reachable" is required in the sample, and the could-not-decide list names what we cannot show. This is evidence for your engineers, not assurance, certification or an audit opinion. |
| A reachability tool misses dynamic or reflective use. | The report names each tool's known limits and marks alerts where those limits apply as could not decide. |
| An automatic fix changes behaviour or adds a fabricated package. | Fix pull requests need passing tests, and each new package is checked against the registry. GitHub's own autofix docs warn that fixes can break semantics. |
A separate automated reviewer checks the work before hand-over. Your named engineer re-checks 10 sampled dismissals and decides every dismissal on the platform. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the severity, the tool, the ecosystem and the could-not-decide rule
- Read the alerts and build the project in a sandbox
- Run the named tool; record commands and output for each alert
- Decide each alert from tool output; open fix pull requests for patchable ones
- Separate automated reviewer checks every dismissal; your engineer re-checks ten
- Hand over the table, evidence, pull requests and the list of unknowns
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
To triage new alerts month after month, a monthly service is offered separately.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Use Dependabot auto-triage rules to snooze alerts that do not apply, and review the first dismissals by hand. docs.github.com
- Run a language-specific vulnerability scanner that reports reachable findings yourself and keep its output with each dismissal.
Questions
Will you dismiss alerts for us?
No. We propose dismissals with evidence, and your people dismiss. Nothing is dismissed on the platform by us.
Is this a security audit?
No. It is evidence for your engineers. It is not assurance, certification or an audit opinion.
What if no tool exists for our language?
We say so at the start and do not guess. The dependency fix job may suit better.
How is this different from the secret-scanning and code-scanning alert service?
This one covers Dependabot and other dependency alerts, with a named tool's output you can re-run. The other covers secret-scanning and code-scanning alerts.
Send an enquiry
Send us
- Your language, package manager and how many alerts are open by severity
- Why you need the triage: a questionnaire, an audit or backlog
- No code, alert details or logins in the first enquiry
Later, once you agree
- A Read-only account or an export of the alerts
- Read-only code at one commit through a company-controlled route
- The name of your checking engineer
You keep the repository, the alerts and every dismissal decision. We use a dedicated bot account with the least access that works (read-only first), work on a fork or branch, and you merge, with read access to alerts and code. Our automated agents read the files you send in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “security-alerts-triaged-with-reachability-evidence” as the subject.