Loading story…
Two pieces of AppSec engineering guidance highlighted how developer tooling and detection techniques are evolving alongside AI-assisted software development. A discussion on modern application security emphasized that even memory-safe languages like Go can still accumulate security risk through flawed patterns and legacy style, and argued that automated, AST-based refactoring (e.g., go fix) can improve readability and reduce mistakes—an effect that can translate into more secure and maintainable code. It also noted a practical AI-development concern: LLMs often reproduce outdated or disfavored coding styles because of their training data, potentially generating “legacy from the start” code unless teams enforce modern conventions through tooling.
Separate research on secrets scanning argued that entropy-based filtering—commonly used after regex candidate capture—struggles with generic secrets and can produce false positives because many non-secret strings (e.g., UUIDs, base64, dependency artifacts) can look similarly “random.” The post proposed reframing the problem as “rare, not random,” and explored Byte-Pair Encoding (BPE) tokenization as an alternative primary filter to better distinguish statistically unusual secret-like strings from normal human-written text, alongside additional rule-based filters (e.g., excluding known safe files such as go.sum).
Track how attackers are adapting to this technology.
3 events from the most recent confirmed update back to the earliest known activity.
The Aikido post says the token-efficiency approach was implemented in a Gitleaks-derived scanner called Betterleaks. Reported benchmark results show improved F1 scores on CredData compared with entropy-only configurations and with CredSweeper's published performance.
Aikido published research arguing that secrets are better identified as rare or out-of-vocabulary strings than simply random-looking ones, and proposed a Byte-Pair Encoding-based metric called token efficiency for post-regex filtering. The post reports stronger separation of secrets from non-secrets than Shannon entropy on the CredData dataset, especially for generic secrets and short passwords.
The SC Media podcast segment says Go maintainers have seen large language models generate disfavored or legacy Go patterns because models were trained on older code, creating maintainability and potential security concerns. The discussion highlights AST-based modernization tooling such as go fix as a way to improve readability and reduce human error.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Security reporting and vendor research highlighted accelerating **AI/LLM security exposure** as enterprises deploy generative AI and autonomous agents faster than defensive controls mature. Commonly cited weaknesses included **prompt injection** (reported as succeeding against a majority of tested LLMs), **training-data poisoning**, malicious packages in **model repositories**, and real-world **deepfake-enabled fraud**; one example referenced prior disclosure that a China-linked actor weaponized an autonomous coding/agent tool by breaking malicious objectives into benign-looking subtasks. Separately, commentary on AppSec programs argued that AI-assisted development is amplifying alert volumes and making traditional **SAST triage** increasingly impractical, pushing organizations toward more *runtime* and workflow-embedded testing approaches. New and emerging tooling and practices are being positioned to address these risks, including an open-source scanner (*Augustus*, by Praetorian) that automates **210+ adversarial test techniques** across **28 LLM providers** as a portable Go binary intended for CI/CD and red-team workflows, and discussion of autonomous AI pentesting tools (e.g., *Shannon*) that require sensitive inputs such as source code, repo context, and API keys—raising governance and data-handling concerns even when used defensively. Several other items in the set (phishing/XWorm activity, healthcare extortion group “Insomnia,” Singapore telco intrusions attributed to **UNC3886**, and help-desk payroll fraud) describe unrelated threat activity and do not materially change the AI-security-focused picture.
Jun 29, 2026
Multiple studies and industry reports found that **AI-generated or "vibe-coded" software is frequently shipped with serious security flaws**, including XSS, SQL injection, hardcoded secrets, unsafe `eval` usage, weak authentication logic, wildcard CORS, exposed `.env` data, and insecure dependencies. One analysis of 5,600 publicly accessible AI-built applications reported more than 2,000 high-risk vulnerabilities and over 400 exposed secrets, while a separate review of 549 self-described AI-generated repositories found widespread committed secrets, injection issues, hardcoded passwords, and other common sanitization failures. Veracode and other researchers similarly warned that code produced by large language models often maps to **OWASP Top 10** weakness classes and that repeated AI-assisted edits, poor prompts, and excessive agent permissions can further increase risk. At the same time, researchers and vendors highlighted both the promise and fragility of AI-assisted security tooling. Trail of Bits reported that OpenAI Codex goal-based prompting helped uncover previously unknown bugs in projects including **Rust**, **curl**, **zlib**, and **Keycloak**, but stressed that human experts were still needed to scope goals, validate findings, and handle disclosure. New academic work also showed that **LLM-based vulnerability detectors can be easily misled**: the ALIBI framework used adversarial code comments to evade four detectors with success rates above 90%. In response to growing concern over agent reliability, Amazon backed the Lean language project to strengthen formal verification for AI agents, while security experts argued that theorem proving can improve assurance for high-risk components but should be applied selectively as part of broader defense-in-depth.
Aug 4, 2026
Security researchers highlighted multiple ways **LLM adoption can introduce or amplify risk**, including both technical attacks and unsafe development practices. G DATA reported that a Git-hosted “detector” for the **Shai-Hulud worm** shipped with “test files” that were effectively *real malware*: scripts capable of deleting user directories and, in at least one case, uploading data to actual threat actors. The files were apparently intended to validate detection efficacy and may have been produced via AI-assisted “vibe coding,” where the model replicated malicious behavior one-to-one while comments claimed the code was only a simulation; although the test artifacts are not executed during normal tool operation, users could trigger damage by manually running them. Separate academic work summarized by Bruce Schneier described **side-channel attacks against LLM inference**, where data-dependent timing and token/packet-size patterns (including those introduced by efficiency techniques like speculative decoding) can leak information about user prompts even over encrypted channels. Reported impacts include inferring conversation topics with high accuracy and, in some settings, recovering sensitive data such as phone numbers or credit card numbers via active probing. In parallel, an SC Media segment discussed the operational upside of **LLM-driven secure code analysis**, citing results that improved security across hundreds of open-source projects but noting the importance of human validation and patching effort; an OSINT Team post provided a cautionary, practitioner-level example of how easily malware can be accidentally executed during analysis, reinforcing the need for disciplined handling and isolation when working with suspicious files.
Jun 29, 2026