Job security-review-of-one-repository-as-a-report-with-evidence · revised 12 October 2026
Get a security review of one repository, with evidence your security lead can re-run
A written review of one repository. Each finding has file, line, quote and a way to re-run it, and a list says what was not examined. It is not a penetration test or a certificate.
You might be seeing
- A questionnaire asks how you review your own code
- Fast AI-written code has never had a security read
No passwords, keys, card details or admin invites needed to start.
What usually happened
Fast, AI-assisted code can carry the usual flaws: injection, weak access checks, secrets in code and unsafe dependencies. A review that lists problems without evidence cannot be checked, and one that says "secure" cannot be kept. Findings need a file, a line and a way to re-run them, and the report must say what it did not look at.
Who it’s for: Founder or engineering lead with a customer security questionnaire, a funding or sale review, or code written fast with AI assistants, who wants a second look at one repository.
Usually starts when: A customer asked for evidence about your code, or an AI assistant wrote much of it and nobody has looked for vulnerabilities.
The result: You receive a written report on one repository at one commit. Every finding gives file and line, a quoted excerpt, its class, a proposed severity for your security lead to set, and how to re-run the evidence, such as a scanner rule, a command or a failing test on a copy. A script confirms every citation, a list says what was not examined, and it is not a penetration test, an audit or an assurance that the code is secure.
Check whether this job fits
Answer these without sending files, tickets, code or logins. Nothing is submitted unless you choose to contact us.
What you get
- The findings report with file, line, quote, class and how to re-run
- The scanner output and the citation check log
- The failing tests for high findings, on a copy
- The not-examined list
- A proposed fix for each finding, as text and not as a change to your code
Included
- One repository at one named commit, read-only, up to 25,000 lines of your own code in languages that the agreed scanners support
- Static analysers agreed in writing for each language, run on a copy, with their output kept
- A read of authentication, access checks, input handling, secrets and dependency use by an automated reader, with every claim tied to a quoted line
- A failing test on a copy for each finding rated high, where a test is possible
- A report with a not-examined list, and a short call for your security lead to ask questions
Not included
- Testing your live systems, networks or any system you do not own
- A penetration test, an audit, a certificate or a statement that the code is secure
- Changing your code or opening pull requests
- Legal or compliance conclusions, such as a view on a standard or a law
- Finding every flaw: a review of this kind cannot
- Printing any secret found: it is masked and listed as a finding
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A script confirms that 100% of cited files, lines and quoted excerpts in the report exist at the named commit.
Evidence: The citation check log.
After the report is frozen, your security lead selects 15 findings, or all if fewer, and uses the supplied evidence to check each. At least 14 of 15 must be real as described; if fewer than 15 exist, all must be real, and one wrong file, line or quote fails the whole test. If there are no findings, this check is marked not applicable and the planted-flaw check still must pass.
Evidence: The selected findings and your lead's marks beside ours; not applicable if none.
On the 8 planted flaws your lead added and kept from us, the report lists which were found and which were missed. The test passes if all 3 planted flaws of the critical kinds (hard-coded secret, injection, missing access check) are found; the count of the other 5 is reported, not promised.
Evidence: The full 8-flaw table with the 3 critical planted cases identified, the detection evidence and your lead's marks. These are held-back smoke tests, not a general detection-rate claim.
Every high finding has a failing test on a copy, or says why no test was possible, and every scanner finding carries the rule id and command to re-run it.
Evidence: The tests and the scanner output.
The report has a not-examined list, and contains no secret in plain text (a script search of the report for the planted canary secret finds nothing).
Evidence: The not-examined list and the script's search result.
Sign-off. You re-run the acceptance checks with the steps we hand over, read the results and sign off in writing. Payment follows sign-off.
If it fails. If an agreed check fails, you do not pay for this 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
- A repository you may share with a model provider named in the written terms, through a company-controlled route
- A named security lead or senior engineer who sets severity and replies to questions
- A languages list that the agreed scanners support
- 8 planted flaws that your lead adds to a copy and keeps from us until the test run
We stop and tell you if
- The code is under a licence or contract that forbids sharing
- You want a certificate, an audit opinion or a statement that it is secure
- You want live systems tested
- A real secret or sign of a break-in is found: we stop and tell your named person at once
What could go wrong
The review reads and reports, so there is nothing to undo. We delete our copies of your code when the job ends and the written terms say when. The report is confidential and goes only to the people you name.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A real flaw is missed and the report is read as an all-clear. | The report does not promise to find every flaw, lists what was not examined and reports how many of your 8 planted flaws it found. |
| A finding is wrong or invented. | A script confirms every file, line and quote exists, and your lead re-checks a sample. A finding with no re-runnable evidence is labelled as a reading only. |
| The report is itself sensitive. | It goes only to named people, secrets are masked, and our copies are deleted on a stated date. |
| Hostile text in code or comments steers the reader. | Code is treated as data, the reader has no tools that change anything, and the sandbox has no secrets. |
A separate automated reviewer checks the work and the test results before hand-over. Your security lead sets every severity, re-checks a sample of findings and decides what to fix. No human supervisor from us 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 commit, languages, scanners, severity owner and terms in writing
- Receive read-only code; plant-test copy is made by your lead
- Run the agreed scanners on a copy and keep their output
- Read auth, access, input, secret and dependency use; tie claims to lines
- Script-check every citation; independent automated review of findings
- Send the report, not-examined list and failing tests; hold the call
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date in writing before you accept, and work starts only after the agreed inputs are in place. An enquiry creates no charge or booking.
Need to keep it working?
Discuss a re-review of the changes since this commit, as a separate job.
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
- Turn on your platform's own code scanning and read its alerts yourself.
- Commission a penetration test or code audit from a security firm if you need a certificate.
Questions
Is this a penetration test?
No. It is a read of one repository with scanner output and tied evidence. It does not test live systems.
Will you tell me the code is secure?
No. We list what we found and what we did not examine.
What if you find a real secret?
We stop, mask it in the report and tell your named person at once. You rotate it.
Who sees the report?
Only the people you name.
Does a pass mean it will be right next month?
No. A pass describes items like the test sample on the day of the test. It is not a promise about future items, and it does not replace your own checking.
Send an enquiry
Send us
- The language, rough size and what the repository does
- Whether the code may leave your systems, and under which terms
- What triggered the request
- No logins, keys, customer data or payment details in the first enquiry
Later, once you agree
- Read-only code at one commit through a company-controlled route
- The name of your security lead
- A copy with 8 planted flaws added by your lead, as the held-back test
You keep the repository. We read one commit through a dedicated bot account with the least access that works, read-only first, and run the analysers on a copy in a sandbox with no secrets and no network except the model provider. Code and comments are treated as data, and the agreement names the model provider, country, retention and training status before anything is shared, and we make no "no storage" promise.
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-review-of-one-repository-as-a-report-with-evidence” as the subject.