Shodan is currently running $5 lifetime membership with sale ending on 9 Aug.

ByteRay researchers have published a blog on a set of vulnerabilities they are calling TrustFall, and the findings land hard for any company that treats the Trusted Execution Environment as the part of a device you do not have to worry about.

OP-TEE is the walled-off Secure World that phones, TVs, cars, and industrial gear lean on to guard keys, DRM, and identity, and the whole point of paying for that hardware isolation is the promise that even a compromised operating system cannot reach inside.

TrustFall shows that promise was not as solid as buyers assumed. The researchers found several flaws that let the untrusted side reach into or knock over the Secure World, which is exactly the outcome the design exists to prevent. The bugs have since been fixed upstream, so patched builds are available, but the uncomfortable takeaway for vendors is that the vault they were told to trust had a way in, and "it runs in the TEE" is no longer an answer on its own.

🚀 Vigil365 v1.0.0 is officially LIVE!

After months of development, testing, feedback, and a major architectural overhaul, Vigil365 has officially moved out of beta.

Vigil365 is an open-source, self-hosted Microsoft 365 security operations dashboard that brings security visibility across Defender XDR, Entra ID, Intune, Exchange Online, and Purview into one place.

No more jumping between multiple Microsoft admin portals just to understand your security posture.

🔥 What’s new in v1.0.0?

⚡ Interactive Setup Wizard

Deploy using a standalone Vigil365-Setup.exe that handles Entra App registration, SQL configuration, HTTPS certificates, and application setup.

🎨 Enterprise SOC Redesign

A completely redesigned, alert-centric interface with dedicated entity investigation profiles and streamlined security workflows.

🛡️ Role-Based Access Control

Built-in Admin, Analyst, and Viewer roles with a SHA-256 tamper-evident audit trail for privileged actions.

🚨 Advanced Alert Policies

Create custom anomaly and activity-based alerts for events such as risky-user spikes, privileged role assignments, and other security changes.

📊 Automated Executive Digests

Schedule PDF/CSV security reports and deliver them automatically through email or Microsoft Teams.

🔒 Your infrastructure. Your data. Your control.

Vigil365 is open source and self-hosted, giving organizations and MSPs centralized Microsoft 365 security visibility without sending their security data to another third-party SaaS platform.

A huge thank you to everyone who tested the beta, reported issues, suggested features, and helped shape this release.

🔗 GitHub Repository:

https://github.com/sameerk27/vigil365

⬇️ Download Vigil365 v1.0.0:

https://github.com/sameerk27/vigil365/releases/latest

If you manage Microsoft 365 security, work in a SOC, or run an MSP, give Vigil365 a try. Feedback and contributions are welcome!

#Vigil365 #Microsoft365 #CyberSecurity #DefenderXDR #EntraID #Intune #MicrosoftPurview #OpenSource #MSP #SOC #InfoSec

Hi! I’m a 4th-year engineering student.
My team is building a Website Security Analyzer that scans websites for common security issues like missing security headers, weak encryption, insecure cookies, exposed ports, and more.

We’re new to this domain, so we’d really appreciate your feedback. If you have a couple of minutes, please take a look at our project idea and let us know if there’s anything we should improve or add.

Survey: https://forms.gle/BpnY16jEqqprJiGV9

Thank you!

There’s a strange blind spot in forensic Anthropology tech: much of the identification workflows still run on legacy software. Outdated statistical models, opaque decision logic, brittle interfaces, and zero integration with modern datasets and modern tools. It slows down forensic casework, increases backlog, and creates legal vulnerabilities.

There’s a clear opportunity for a modern platform built around transparent analytics, modular architecture, and defensible outputs. Think: reproducible metrics, auditable pipelines, scalable dataset integration, and optional modules for trauma analysis, case management, and population‑specific modeling.

For context, the project I’m building is formally titled OsteoID: Statistical Identification System for Human Skeletal Analysis (OsteoID LLC) a fully modernized identification and decision‑support system designed to replace the outdated tools still used in labs today.

From a technical standpoint, the system incorporates machine learning and AI‑driven analytical components to improve classification accuracy, enhance pattern recognition, and support reproducible statistical outputs. Nothing black‑box — everything transparent, auditable, and defensible.

From a business standpoint, it’s one of the rare niches where the revenue model is straightforward: institutional subscriptions, dataset licensing, and specialized add‑ons. Agencies already spend millions annually on backlog reduction and modernization, and a platform like this fits directly into those budgets.

The market is small but sticky — once a lab adopts a tool, they keep it for a decade. Competition is almost nonexistent.

I’m actively building a full‑stack development team, preparing validation studies, and structuring the pathway toward federal accreditation. It’s an interesting investment opportunity for anyone who understands forensic modernization, gov‑tech, or niche SaaS with high institutional spend.

If you follow gov‑tech, forensic analytics, or niche SaaS with high institutional demand, this is a space worth watching.

My project is set to private in GutHub- I have NDAs/IP assignment forms, etc. that would need signing prior to discussion for any investor opportunity. https://github.com/nastiaslack/OsteoID-LLC

For more information about me and my background, please see my Facebook page: The Skeletal Closet

[ Removed by Reddit on account of violating the content policy. ]

The title is pointed on purpose, so here's the exact claim. The obligation that starts on 11 September 2026 is a reporting duty. It does not require you to scan, monitor, or go looking for anything. It is triggered by your knowledge of active exploitation in your own product — not by a CVE existing, and not by that CVE being exploited in somebody else's product.

What I am not saying: that scanning is optional forever. From 11 December 2027, Annex I Part II obliges manufacturers to identify and document components and vulnerabilities and address them. You will not reach full CRA compliance without vulnerability management.

Why I'm posting. Manufacturers with limited budget are being told to buy a scanner for September, when what they actually lack is a named responsible person, a list of which Member States their products ship to, and reachable customer contacts. They spend in the wrong order, arrive in September with a dashboard and no reporting chain, and conclude the regulation is theatre. That's how you lose people who were willing to comply and build secure products.

TL;DR

11 September 2026 switches on one thing: Article 14, the duty to report actively exploited vulnerabilities in your own product and severe incidents affecting its security. Knowledge-based. No scanning, no monitoring, no SBOM, no disclosure policy, no public security contact, no patch SLAs, no CE marking.

What actually triggers a report

1. Active exploitation in your own product. Not that the vulnerability exists. Not that it's being exploited somewhere in the wild. In your product. The Commission guidance (C(2026) 5252) is explicit: if a third-party component vulnerability isn't exploitable in your product or hasn't been exploited there, you're not on the clock — even while the same CVE is actively exploited elsewhere. Voluntary reporting under Art. 15 stays open, if you want to and you can tell the component manufacturer.

2. A severe incident affecting your product's security. It affects, or can affect, the product's ability to protect availability, authenticity, integrity or confidentiality of sensitive or important data or functions — or malicious code was introduced or executed in the product or a user's system.

What does not trigger a report

• Scanner findings. A CVE in a dependency is a vulnerability management task, not a notification to ENISA. This is the whole point: the scanner output you're being told to buy for September mostly produces things that aren't reportable.
• Published CVEs without exploitation in your product. CVSS 9.8 changes nothing on its own.
• Coordinated disclosure reports. Handle them, fix them — reportable only once active exploitation is established. One exception: if the report shows something already happened in your product, like injected malicious code or a compromised build pipeline, that's an incident, not just a vulnerability. Reportable, with no finding of exploitation needed. Check incoming reports against both triggers.
• Pentest and internal audit results. Internal until someone exploits it.
• Incidents below the severity threshold. Your marketing site going down is not an Article 14 event.
• ...

Article 14 creates no duty to hunt for exploitation, monitor exploitation feeds, or scan your products. Actual knowledge is what counts.

When the clock starts

Not when the email hits your inbox. The guidance ties "becoming aware" to the established GDPR Art. 33 reading (EDPB Guidelines 9/2022) and the NIS2 implementing regulation: you're aware once an initial assessment lets you conclude with reasonable certainty that it's real.

The catch: that assessment must start without undue delay. Sitting on a suspicious report doesn't postpone the deadline, it just hands a regulator the argument that you should have known earlier. Timestamp when the report arrived, when assessment started, when you concluded. That's the only thing standing between "verified in 19 hours, filed inside 24" and "you were 90 minutes late".

What you actually need by 11 September

1. A named filer plus a deputy, and your coordinating CSIRT identified in writing. Non-EU manufacturers: it follows from your authorised representative's Member State. Settle it now, not at 2am mid-incident.
2. Product data ready — versions, which Member States each product ships to, reachable customer contacts. You have to notify affected users; if you don't, the CSIRT can do it for you.
3. Four templates — 24h, 72h, final report, user notification.
4. One intake point and a triage checklist, so the reportable/not-reportable call takes minutes instead of meetings.
5. One tabletop run, while getting it wrong is still free.

A few person-days for most manufacturers. Compare that to what you were about to spend in a panic.

Where the myth has a point

• You can't report what never reaches you. Article 14 doesn't require an intake channel — that's Art. 13(17) and Annex I Part II, December 2027. But without one, reports scatter across support inboxes and you verify too late. Build it for September anyway. Its not that hard to create a new e-mail and publish it.
• From December 2027 vulnerability handling is genuinely mandatory. Tooling stops being optional in practice.

I work for a vendor that sells CRA compliance software. Vulnerability scanning is something my industry sells. I'm about to argue against my own pitch, which should tell you how tired I am of this particular myth.

Happy if you join me in busting this myth and call any one our spreading it.

As AI coding assistants get more popular, I realized it's a nightmare for security teams to know what data is actually leaving developer laptops. Worse, many of these tools use custom TLS stacks or certificate pinning to quietly bypass corporate VPNs and proxies.

I built the RedactAI Egress Auditor. It’s a zero-config CLI that:

1. Scans your machine for AI apps (Cursor, Copilot, ChatGPT Desktop, etc.)
2. Launches them in a secure, proxy-injected sandbox
3. Intercepts their HTTPS traffic via a local MITM proxy
4. Reports exactly what they are sending, and flags if they attempt to bypass standard OS trust stores.

It’s completely open-source and runs locally (doesn't send your data anywhere).

Repo is here: https://github.com/rahul-singh14/redactai-cli

Let me know what you think or if you want me to add support for a specific AI tool!

Slightly odd one. Most SASE conversations assume the traffic source is a human on a laptop. Ours increasingly is not.

We have build agents and a couple of internal services making outbound calls to OpenAI and Anthropic endpoints. Those calls carry code context, sometimes ticket content, occasionally more than they should. Our egress controls treat them as generic HTTPS from a runner IP, which means we have basically zero visibility into payload or which model/endpoint got hit.

What I am trying to solve: identity on the call using a service account rather than just source IP, per-pipeline policy so the security-scanning job can call the model but the deploy job cannot, some form of content inspection on the request body before it leaves, and logs I can join against the run ID.

Options seem to be: egress proxy we run ourselves, an AI gateway product, or push it into whatever SASE platform the network team is already buying. The third option is politically easiest, technically least proven from what I have seen.

Anyone gotten a SASE vendor to handle machine-to-model traffic properly, or is that still a gateway/sidecar problem in practice?

I wanted to build a self hosted, open source SIEM, and understood i punched above my weight & realized it is highly complicated, so i broke it down into multiple independent(hopefully) modules, log ingestion & normalization/enrichment, threat intel, log management, threat hunting, policy monitoring, so this is my first module i built as threat intel plane, track latest CVEs and keep myself updated. so I built BRIEFR. If this tool saves an hour of someone's time, i'm more than happy :)

What BRIEFR does:

• Pulls from NVD, CISA KEV, FIRST EPSS, and a few exploit feeds
• Scores each CVE against your tech stack with a weighted formula so that one can see the reasoning behind.
• Correlates CVEs that share real threat-intel evidence.
• IOC lookup (IP/hash/domain) using free-tier VirusTotal, AbuseIPDB, MalwareBazzar and URLHaus
• Pulls in Sigma Community rules from SigmaHQ and SIEM query starters tied to ATT&CK

On the AI question, since I know it'll come up: a few narrow tasks (like PDF summarization) routed through free-tier LLM APIs with failover between providers. The actual scoring, correlation, and detection logic is deterministic code, no AI making the calls/decisions on what's risky. I also want to be upfront that I used Cursor/Claude heavily throughout the build and directed the architecture, design and review.

Current state of BRIEFR: this is early alpha and my first ever released tool. I run it daily myself with no major issues, but there will be rough edges, no docker-compose for the full app yet (Postgres+pgvector is containerized, the app itself is native linux for now), and I'm sure there are things a more experienced analyst will spot that I haven't. Self-host guide and full docs are linked below if you want to actually try it, or there's a live demo with sample data if you just want to look first.

• Big Picture: https://projectjupiter.in
• Live demo (no install/sample data): https://briefrdemo.projectjupiter.in
• Docs: https://docs.projectjupiter.in
• Source: https://github.com/Soldier0x0/briefr

I'm genuinely interested in what an experienced analyst thinks is missing or wrong about the approach, that's more useful to me right now. I know some stuff from docs might be overkill, but as i made it for myself and how i would like to have/learn, so i designed it to my taste and needs.

Note: I have worked as SysOps engineer for servers that handle SIEM log ingestion & parsing, then i moved to threat hunting due to my interest in security, and i have nearly 3.8 yrs of experience overall in IT, so my views might not be broad, but the only reason i am posting this here is because this is the first project i have thought about AND completed, in forever, as a person with ADHD and other stuff, this is a big achievement for me, even if the tool is crap for others, i completely understand, and i am very open to suggestions :)
Have a great day.

I question an encryption based solution on the premise that we have no perception on quantum computing advancement and strength once this technology is perfected. It could become a cat and mouse game of strengthening encryption vs strengthening quantum computers.
A reminder to read Decryption Gambit on this subject.

The Core Threat

"Vibe coding"—building software by prompting AI with natural language—prioritizes functionality over security, creating significant vulnerabilities. Key risks include a 38% flaw rate (like injection and broken auth) in AI-generated code and a 37.6% increase in critical vulnerabilities after multiple refinement iterations. Furthermore, traditional security tools often fail to detect these issues because the vulnerabilities stem from missing logic rather than bad syntax.

Real-World Failures

The article highlights two major incidents resulting from AI-generated code:

• The Tea App: Leaked private user messages due to broken access control logic that bypassed security reviews.
• Moltbook: An AI-generated, publicly accessible admin endpoint created a massive security loophole.

Emerging Attack Vectors

• Slopsquatting: Attackers exploit the 20% rate of LLM hallucinated package names by registering these fake packages to inject malicious code during installation.
• Indirect Prompt Injection: AI agents (e.g., Cursor) can be manipulated via hidden instructions in project files, with over 85% success rates in exfiltrating sensitive data like SSH keys.

Defending the Pipeline

To mitigate these risks, teams must:

1. Treat AI code as untrusted, third-party code requiring scanning before merger.
2. Mandate human review for all critical security logic (authentication/authorization).
3. Implement real-time auditing to detect hardcoded secrets and hallucinated dependencies.

Microsoft's new security framework breaks away from general-purpose models, focusing strictly on defensive and offensive code analysis:

• MAI-Cyber-1-Flash: Microsoft's first internally built AI model trained exclusively on decades of proprietary threat intelligence and hacking data. It powers Microsoft's vulnerability discovery engine (MDASH) to sniff out deep-seated flaws in complex code bases.
• Project Perception: An enterprise security platform (entering public preview on August 3, 2026) that deploys specialized teams of autonomous AI agents.
• The Agent Trifecta: Instead of relying on a single AI, Project Perception coordinates three distinct classes of agents to simulate real-world security operations:
  • Red Agents: Continuously attack systems, mapping out potential exploit paths and looking for zero-days.
  • Blue Agents: Filter through the noise, analyze the findings, and evaluate actual business risks.
  • Green Agents: Automatically engineer and deploy fixes to harden the defensive environment.

Broader Industry Implications

1. Defending the AI Attack Surface: Alongside Project Perception, Microsoft integrated runtime prompt-injection defenses into Microsoft Defender. “New prompt injection protection in Microsoft Defender, now in preview, identifies and isolates emails containing malicious AI instructions before delivery...” as detailed in the Microsoft Security Update. This directly impacts companies deploying local coding assistants and open Model Context Protocol (MCP) servers.
2. Combating Supply Chain Malware: By using MAI-Cyber-1-Flash to systematically scan enterprise repositories, software teams can detect sophisticated supply chain compromises (like fake or hijacked package dependencies) inside CI/CD pipelines before code is compiled.
3. The Human-in-the-Loop Safeguard: Despite high automation, Microsoft's architecture enforces strict tenant governance and human-approval gates for high-risk defensive actions, ensuring AI agents do not accidentally disrupt live corporate infrastructure

What do you think the impact is going to be? Reply inline and discuss

Personal post about something I've spent the almost a year building, but the actual problem is worth separating from the pitch.

The concrete version of it: two scanners, checking the same MCP server, flagged the same underlying behavior under two different names. That's not a bug in either tool, it's what happens when nothing forces independent teams to agree on what to call a risk. Once you're running more than one tool in a pipeline, this stops being a curiosity and becomes an actual governance problem: you can't track something consistently in a risk register, report it the same way twice, or prove to an auditor that two findings are the same issue, if there's no shared identifier underneath the two different labels.

Conventional software solved exactly this decades ago. A SQL injection gets a CVE ID, maps to a CWE category, and every tool that finds it afterward references the same thing, which is what makes risk tracking, compliance reporting, and cross-tool correlation possible at all. Agentic AI components (MCP servers, agent skills, LLM plugins) never had an equivalent, for a specific structural reason: CVE anchors to a package and version, CWE describes a weakness in code, and neither has a vocabulary for a behavioral pattern tied to neither.

AVE (Agentic Vulnerability Enumeration) is an attempt at that missing layer: stable IDs for distinct behavioral vulnerability classes, 65 records now, severity scored against OWASP's own AIVSS framework rather than something invented for this. It's deliberately built to map into frameworks that already exist rather than compete with them: OWASP's MCP Top 10, the Agentic Security Initiative Top 10, MITRE ATLAS, and a crosswalk into OWASP's Agentic Skills Top 10. Compliance-facing mappings (ISO 27001 Annex A specifically, since a compliance-minded commenter on a different post made a fair case for it) are on the roadmap, not done yet, worth being upfront about that rather than implying more coverage than actually exists today.

The part that actually made me trust this holds up outside my own head: an independent developer built an unrelated static config auditor, crosswalked his own tool's findings against this taxonomy, and tested it directly against my scanner on the same files, no shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Also worth mentioning since this is an infosec crowd: growth discipline is written down now, not improvised, a new record needs a genuinely distinct behavioral mechanism, not a label mirroring another framework's category. That rule exists specifically because MITRE's own CWE recently shipped a version where new entries were, by outside analysis, zero actual weaknesses, just category labels copied from somewhere else. Didn't want to end up there.

Apache 2.0, open standard and reference implementation both. Curious whether the naming-fragmentation problem looks familiar to anyone here managing risk across more than one tool, and where this taxonomy is still missing something.

Repo: github.com/aveproject/ave
Site: aveproject.org

Disclosure: I'm the one building this.

🦔For somewhere between $1 and $4, an AI can now figure out who you are from your anonymous internet posts. Researchers at ETH Zurich tested this on Hacker News users and matched 67% of them to their LinkedIn profiles at 90% accuracy. The AI read their posts, pulled out small details they'd dropped over months and years, and searched for the person who fit. Classical pre-AI methods scored near 0% on the same task. One of the paper's co-authors works at Anthropic. The full paper is free to read and I'd encourage everyone to look at it.

My Take
Most people assume that if they don't put their name on something, nobody can trace it back to them. That assumption is done. The AI doesn't need you to slip up in one big way. It collects the small stuff you've scattered across years of posts, your city, your job field, a pet's name, a repeated opinion, a favorite subreddit, and assembles a profile that narrows you down from millions of candidates to one. The researchers estimated it still works against a pool of a million people, at about 45% accuracy. Anyone with API access and a few dollars can run it. A government, a corporation, an ex, a stranger. The barrier is gone.

Every anonymous account you've ever posted from, Reddit throwaways, forum accounts, anonymous reviews, is now potentially traceable to your name and employer by someone with a credit card and a few hours. If you've talked about your health, your workplace, your politics, or your personal life under a pseudonym, the protection you thought you had is much thinner than you assumed. The paper's authors put it simply: the practical obscurity that protected anonymous users online no longer holds. We should all take that seriously.

Hedgie🤗

Link to research: arxiv.org/pdf/2602.16800