Standing service security-secret-and-code-scanning-alerts-triaged-each-month · revised 12 October 2026
Standing service
Get each month's new secret and code-scanning alerts sorted, with what to fix first
Each month new secret-scanning and code-scanning alerts are classed fix now, can wait, false positive or needs an owner, with evidence. No code changed, no alert closed. Dependabot is separate.
This starts a conversation by email. Nothing is charged, and nothing is reviewed, until we have agreed scope, access and terms with you in writing.
The responsibility you hand over
New code-scanning findings and secret matches arrive every week, and a repository that was sorted once fills up again within months. A developer must read each alert and check the flagged code or value. When nobody has that hour, the real issue is buried again.
Who it’s for: CTO or lead developer with new secret-scanning and code-scanning alerts arriving every month and no time to sort them.
Usually starts when: You cleared the alert backlog once, new alerts keep arriving, and the team is drifting back to ignoring the list.
The result: Every month you get a sheet of the month's new alerts, each classed fix now, can wait with a reason, false positive with evidence or needs an owner. Alerts classed can wait are rechecked in case the alert or the flagged code has changed. We make no code changes and close no alert.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target for delivering each report is agreed in writing before it starts, set to what a service at this stage can actually keep.
Runs once a month after the period closes. Not staffed round the clock.
What must remain true
- Every alert opened in the month is classed with evidence, or listed as needs an owner
- No alert is dismissed in GitHub by us
- Alerts classed can wait are rechecked each month against the current alert and flagged code
What we watch
- New alerts from your repositories
- The flagged files, and the lines around each secret match with the value removed
- The previous month's sheet
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A month closes and the alerts are available. | We sort the new alerts and send the sheet to the person you named. |
| A code-scanning alert is on a line that untrusted input reaches. | We class it fix now and put it first, with the line. |
| A can-wait alert is raised in severity or its flagged code changes. | We move it up and say why. |
| An alert is a secret that may still be valid. | We tell you to rotate it now and offer the secret-removal job. Linked job: Remove a committed secret |
We do on our own
- Read the alerts and the flagged files
- Class each alert and write the evidence
- Propose the fix order
We ask you first
- Wider repository access
- Any request to change code or close an alert
- More repositories or alerts than the agreed limit
We escalate to you when
- An alert is a possibly live secret
- A fix-now alert stays open two months running
- The token expires or access changes
How you know it held. Each month you can count the alerts opened and the rows in the sheet and find they match, and every can-wait row cites evidence a developer can open.
How we keep it true
This service is never finished. Each period's summary shows whether the thing it watches stayed true, and it continues until you end it.
Get open secret and code-scanning alerts sorted into fix now, can wait and false alarm Job Optional
Each open secret-scanning and code-scanning alert is classed fix now, can wait, false positive or needs an owner, with evidence. We change no code and never use a found secret. Dependabot is separate.
Bought separately, once
The one-off sort of an existing backlog before the monthly service starts.
What is included, and what is not
- A monthly triage sheet with evidence
- The recheck list
- The proposed fix list
Included
- Up to 3 repositories and up to 40 new secret-scanning and code-scanning alerts a month, from an export you create or, for code scanning, a read-only token
- A class, the evidence and a usage note for each new alert
- A recheck of alerts already classed can wait, in case the severity or the flagged code has changed
- A secret alert is false positive only for a documented placeholder or test value, and can wait only where the alert records the secret as revoked or inactive
- A short proposed fix list in order, for your developers to carry out
- Scripts read the alert data and the flagged files; the language model reads each alert and the code around it to explain the class
Not included
- Changing code, merging or opening pull requests
- Dismissing or closing any alert in GitHub
- Dependabot and other dependency alerts (use the monthly dependency alert triage)
- Handling a confirmed live secret exposure
- Testing, using or confirming that a found secret works
- Scanning your running systems
- Any statement that your software is free of vulnerabilities
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On 30 alerts you marked fix now, can wait or false positive, with your answers held back until we hand in ours, at least 27 of our classes match. A pass at 27 of 30 shows the true rate is at least 76% with 95% confidence, for alerts like these. The 30 include at least 5 of each class, so one label for everything cannot pass.
Evidence: The confusion table of our class against yours. Needs-an-owner counts as a miss.
Every can-wait and false-positive class cites a file path and line, or alert text, that a developer can open. A can-wait or false-positive class for a secret that is not a clear placeholder and not recorded as revoked or inactive, or for a reachable code flaw, fails the whole test.
Evidence: The evidence column checked on every row.
Each month the number of rows equals the number of alerts opened in the month, and our token was refused when it tried a test write and a read of secret-scanning alerts.
Evidence: Alert count against sheet rows, and the refusal messages.
Sign-off. You read each sheet and tell us whether the classes and the fix order still suit you. A month counts as delivered when you have received the sheet.
If it fails. If we cannot complete a period because an export is missing or has changed, we say so, explain what we need 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
- An export of the alerts with every secret value removed, or a token you create, scope and revoke that reads code-scanning alerts and files but not secret-scanning alerts
- A developer who owns each decision and can check a sample
- At most 40 new alerts a month on average
- You can mark 30 alerts yourself with the right answer, held back for the first test
We stop and tell you if
- A live secret exposure is confirmed (rotate and revoke first)
- You want us to change code or close alerts
- You want Dependabot or other dependency alerts sorted (a separate service)
- Repositories hold regulated data that cannot be shared even read-only
What could go wrong
The service only reads and reports, so there is nothing to undo. Ending it leaves your systems exactly as they are; you keep every report we sent.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A real vulnerability or live secret is wrongly dismissed | Every can-wait and false-positive class cites evidence a developer can open. A can-wait or false-positive class for a secret that is not a clear placeholder and not recorded as revoked or inactive, or for a reachable code flaw, is a severe error that fails the test. |
| A secret value reaches us or the model provider | You remove every secret value before sending. If one is found in what you send, we stop, tell you to rotate it and delete our copies. |
| Text in alerts or issues steers the automation | It is treated as data, and the token is read-only, so a steered run still cannot change code or close alerts. |
| Your files pass through an AI model provider | The written agreement names the provider type, its country and how long it keeps data before you send anything. Entry jobs use redacted or synthetic copies, or your own provider account if you prefer. We delete our copies when the job ends. |
A separate automated reviewer checks every can-wait and false-positive class against its evidence before it is sent. Your developer checks a sample and decides every class. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
Stays with a person
- Your developer decides every class and any fix
- You revoke the token if you end the service
Access we would need
- A read-only token for named repositories, for code-scanning alerts and files, that you create and can revoke
- Secret-scanning alerts only as your export with the values removed; no write, merge or dismiss rights
Questions
Will you close alerts or fix the code?
No. We sort alerts and give a fix order. Closing alerts and changing code stay with your team.
What about alerts that cannot be judged?
They are classed needs an owner with what we found. We never mark an alert false positive without evidence.
Can I start with the backlog job?
Yes. The one-off job sorts the existing backlog; this service then keeps new alerts sorted.
What about Dependabot alerts?
They are a separate monthly service, with reachability shown by tool output.
Also part of
Send an enquiry
Send us
- How many repositories and how many new secret-scanning and code-scanning alerts a month
- The main languages and the code-scanning tool
- Whether a developer owns the decisions. No tokens, secrets or code in the first enquiry
Later, once you agree
- Secret-scanning alerts as an export with each secret value removed
- For code-scanning alerts, a fine-grained read-only token for named repositories that you create and can revoke, or an export
- A developer who owns each decision
- A list of repositories in scope
- 30 alerts you have marked with the right class, held back from us until the first test
You keep the repositories and every decision. We read code-scanning alerts and flagged files through a read-only token you create for named repositories, and secret-scanning alerts only as the export you make with the values removed. We cannot push, merge or dismiss anything.
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-secret-and-code-scanning-alerts-triaged-each-month” as the subject.