Can your team find security weaknesses in AI code?
Coming soon
Prove your team can do it
Fernbrook Systems
Last 12 months
PNPriya NLast submission 12 AugPassed100/100
MVMarcus VLast submission 9 AugPassed85/100
ERElena RLast submission 28 JulPassed86/100
STSam TLast submission 14 JulWell below66/100
The team report card
Every reviewer and every graded review, in one document.
Access control87 of 128 caught
Injection69 of 96 caught
Authentication39 of 56 caught
Sessions and cookies31 of 42 caught
Coverage by weakness category
Strengths and blind spots, from the findings themselves.
Team catch rate
assessed work only
58%
May
66%
Jun
74%
Jul
85%
Aug
Improvement over time
The catch rate, tracked assessment after assessment.
New assessment
tenantlyMulti-tenant boards, access control focus
PNMVERST4 reviewers · 14 day windowAssign
One submission each, graded on the server, straight into the report.
Set in minutes
Pick a codebase, pick the reviewers, set the window.
Sample figures. Every name and number is invented.
You are already meant to be doing this
Whether the code was written by a human, an AI, or both, it still needs a competent person to sign it off.
Train the reviewers
- EU AI Act Article 4
- “Providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff…”
- PCI DSS 6.2.2
- Developers working on bespoke and custom software are trained at least once every twelve months in secure design and secure coding, relevant to their role and the languages they use.
- ISO/IEC 27001:2022 clause 7.2
- Determine the competence needed for work that affects information security, act where it is missing, evaluate whether that action worked, and keep documented evidence of it.
- NIST Secure Software Development Framework, PO.2.2
- “Provide role-based training for all personnel with responsibilities that contribute to secure development. Periodically review personnel proficiency and role-based training, and update the training as needed.”
- NIS2 implementing regulation for digital infrastructure and digital providers, Annex point 8.2.3
- “The training … shall be relevant to the job function of the employee and its effectiveness shall be assessed.”
- DORA Article 13(6)
- “Financial entities shall develop ICT security awareness programmes and digital operational resilience training as compulsory modules in their staff training schemes.”
Review the code
- PCI DSS 6.2.3.1
- Where manual code review is used before release, it is done by someone other than the author, who is knowledgeable in code review techniques and secure coding.
- DORA RTS on ICT risk management, Article 16(3)
- The procedure for testing and approving an ICT system before it is used “shall contain the performance of source code reviews covering both static and dynamic testing.”
- NIST Secure Software Development Framework, PW.7.2
- “Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.”
- FDA premarket cybersecurity guidance for medical devices (2026), Appendix 1
- “Carefully design and review all code that handles the parsing of external data using automated (e.g., static and dynamic analyses) and manual (i.e., code review) methods.”
- OWASP SAMM, security testing
- “Automated tools are effective at finding various types of vulnerabilities but can never replace expert manual review.”
- NCSC guidance to the UK Software Security Code of Practice
- “Peer/code review: having two or more people review code to check its quality and security.”
Quoted where the text is public; paraphrased where it is licensed.
