Notifications
Clear all
Topic starter
10/06/2026 12:11 am
TL;DR: Anthropic says Project Glasswing, built around Claude Mythos Preview, found thousands of previously unknown zero-day vulnerabilities across major operating systems and browsers, including an OpenBSD bug reportedly missed for 27 years, according to Anthropic. Continuous AI-assisted testing is becoming a practical way to shift security earlier in the development lifecycle, but judgment and context still decide what gets fixed first.
NHIMG editorial — based on content published by Orca Security: Why AI-driven security testing in the development lifecycle could help teams reduce noise, deploy faster, and build safer software
Questions worth separating out
Q: How should security teams use AI-driven testing in the development lifecycle?
A: Security teams should place AI-driven testing inside normal development workflows so findings arrive before production, not after release.
Q: Why does earlier vulnerability discovery matter for release risk?
A: Earlier discovery matters because the cost and disruption of fixing a weakness rise as software moves closer to production.
Q: What do organisations get wrong about AI-assisted security testing?
A: A common mistake is treating better detection as a substitute for governance.
Practitioner guidance
- Embed security testing into delivery workflows Run vulnerability analysis during design, implementation, and release preparation instead of waiting for the final checkpoint.
- Govern the identities behind testing tools Inventory the service accounts, tokens, and API keys used by scanners, analysis agents, and remediation integrations.
- Separate detection from decision authority Allow automated discovery to surface findings quickly, but require explicit policy for what can be auto-remediated, what needs review, and what must stop the pipeline.
What's in the full article
Orca Security's full blog post covers the operational detail this post intentionally leaves for the source:
- How the development lifecycle changes when AI-assisted testing is embedded before deployment
- Why the article argues that continuous investigation reduces downstream security noise
- Where the author sees the balance between automation and human judgment in secure delivery
- What this approach means for teams trying to move faster without weakening assurance
👉 Read Orca Security's analysis of AI-driven security testing in the development lifecycle →
AI-driven security testing in the SDLC: are teams ready?
Explore further
11/06/2026 1:52 am
AI-driven security testing is becoming a control-plane problem, not just an AppSec problem. The article frames the upside as better code review and earlier vulnerability discovery, but the deeper implication is that security testing is now part of the operational identity layer of software delivery. Once tools can inspect, triage, and trigger actions continuously, teams must decide which identities are allowed to initiate that work and under what authority. Practitioners should treat the testing stack as governed infrastructure, not a collection of helper scripts.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: How do organisations know if continuous security testing is actually working?
A: It is working when more issues are found before release, fewer emergency fixes reach production, and engineering spends less time on avoidable investigations. The best signal is not the number of findings alone, but whether the programme is reducing downstream noise and shortening remediation paths.
👉 Read our full editorial: AI-driven security testing is reshaping secure software delivery
12/06/2026 3:27 am
AI-driven security testing is becoming a control-plane problem, not just an AppSec problem. The article frames the upside as better code review and earlier vulnerability discovery, but the deeper implication is that security testing is now part of the operational identity layer of software delivery. Once tools can inspect, triage, and trigger actions continuously, teams must decide which identities are allowed to initiate that work and under what authority. Practitioners should treat the testing stack as governed infrastructure, not a collection of helper scripts.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: How do organisations know if continuous security testing is actually working?
A: It is working when more issues are found before release, fewer emergency fixes reach production, and engineering spends less time on avoidable investigations. The best signal is not the number of findings alone, but whether the programme is reducing downstream noise and shortening remediation paths.
👉 Read our full editorial: AI-driven security testing is reshaping secure software delivery
