Standing service security-alerts-triaged-every-month · revised 12 October 2026
Standing service
Have new Dependabot and dependency alerts triaged with re-runnable evidence every month
Each month new Dependabot and dependency alerts at or above your severity get a decision: fix pull request, proposed dismissal with evidence you can re-run, or needs an owner. We dismiss nothing.
This starts a conversation by email. Nothing is charged, and nothing is read or run, until we have agreed scope, access and terms with you in writing.
The responsibility you hand over
Alerts arrive every month. Without a regular decision on each, the list grows again, and a dismissal made in a hurry has no recorded reason.
Who it’s for: A team that has cleared its alert backlog once and wants new alerts decided with evidence as they arrive.
Usually starts when: New alerts keep arriving and no one has the time to prove each is real.
The result: Each month the new and still-open alerts at or above the agreed severity get a decision with commands and output from a named tool that you can re-run. A list shows what could not be decided. We dismiss nothing on the platform, and the evidence is not assurance.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target for sending each month's report is agreed in writing before it starts.
The service runs once a month after the month closes. It is not a pager and has no round-the-clock cover. Alerts raised between reports are looked at in the next report.
What must remain true
- Every new or still-open alert at or above the agreed severity has a decision each month, or is on the could-not-decide list with the reason
- No proposed dismissal rests on a model's opinion; each cites a named tool and a command you can re-run
What we watch
- Dependency alerts for the repository, read-only
- The code at the current commit, read-only
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A month closes. | We send the decision table, the evidence and the summary. |
| A new critical alert is raised. | We put it first in the next report and, if you ask, run the one-off triage on it sooner. Linked job: Dependabot alerts triaged with evidence |
| Any sign of compromise appears. | We stop and tell you; you follow your incident process. |
We do on our own
- Read alerts and code
- Run the named tool in a sandbox
- Open fix pull requests for you to review
We ask you first
- Anything that dismisses or closes an alert
- Wider access
- More than 2 fix pull requests in a month
We escalate to you when
- Any sign of compromise
- A critical alert that cannot be decided
- The tool or ecosystem support changes
How you know it held. Each month your engineer can re-run the stored commands for any sampled dismissal, open the code the tool reports on, and check that the table counts alerts by decision against the alert export.
How we keep it true
This service is never finished. Each month's summary shows whether what it watches stayed true, and it continues until you end it.
Find out which of your Dependabot alerts actually matter, with evidence you can re-run Job Optional
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.
Bought separately, once
The one-off triage that clears the existing alert list.
What is included, and what is not
- The monthly decision table
- Re-runnable evidence for proposed dismissals
- Up to 2 fix pull requests
- A monthly summary
Included
- One repository in an ecosystem with a usable reachability tool and up to 20 new alerts a month
- A decision per alert with re-runnable evidence
- Up to 2 fix pull requests a month for patchable alerts, on a branch you merge
- A monthly summary and the could-not-decide list
Not included
- Dismissing alerts on the platform
- Assurance, certification or an audit opinion
- Incident response or compromise investigation
- Alerts needing private registry credentials
- Secret-scanning and code-scanning alerts; those are a separate service
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month every alert at or above the severity has one decision or a could-not-decide reason, checked against the alert export.
Evidence: The script count and the monthly table.
Every proposed dismissal cites a named tool and a command that produces the evidence.
Evidence: The evidence column and a script check for empty commands.
Each quarter your engineer re-runs the stored commands for 10 sampled 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 check. It describes the ten sampled.
Evidence: The sampled rows and verdicts.
Nothing was dismissed or closed on the platform by us.
Evidence: Your repository security log.
Sign-off. You read each report and tell us whether the severity and tool still suit you. A month counts as delivered when you have received the table and the summary.
If it fails. If alerts or the tool stop being available we say so and do not guess. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- A usable reachability tool for the ecosystem
- A Read-only account for alerts or a monthly export
- Tests that run in CI
- A named engineer who decides dismissals
We stop and tell you if
- Any sign of compromise
- More than 20 new alerts a month for three months, so a larger scope is agreed
- The tool stops working for your ecosystem
What could go wrong
The service reads and proposes. Fix pull requests can be closed or reverted, and no alert is dismissed by us. Ending the service changes nothing.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A proposed dismissal is wrong. | Evidence is tool output you can re-run, a sample is re-checked each quarter, 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 use. | The report names the tool's known limits and marks affected alerts as could not decide. |
| Volume exceeds the allowance. | The cap is written in the agreement and we say when it is reached. |
A separate automated reviewer checks the work before hand-over. Your named engineer decides every dismissal. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
Questions
Do you dismiss alerts?
No. We propose with evidence; your engineer dismisses.
Is the monthly report an audit?
No. It is evidence for your engineers and not assurance.
What if volume is higher?
We agree a larger allowance in writing or batch the work.
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.
Also part of
Send an enquiry
Send us
- Your language, package manager and monthly alert volume
- Your severity threshold
- No code, alert details or logins in the first enquiry
Later, once you agree
- A Read-only account for alerts, or a monthly export
- Read-only code at the current commit
- The name of your deciding engineer
You keep the repository and every dismissal. 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-every-month” as the subject.