decloak.dev

Resilience Act's first obligations became applicable on 11 September. If you sell software or connected products into the EU, the questions have started. Decloak now maps every scan finding to NIST CSF 2.0 and the CRA, alongside SOC 2, ISO 27001, NIS2, DORA, LGPD and PCI DSS. That makes eight frameworks from one scan, and it works on the scans you already run. Why these two: - NIST CSF comes up in almost every US vendor questionnaire and RFP, even for companies not formally aligning to it. It was the framework customers asked us for most. - The CRA's vulnerability and incident reporting duties apply now. The full regulation, including SBOM and CE marking, follows in December 2027. How it works: - NIST CSF is mapped at subcategory level, the level questionnaires cite. A TLS finding maps to PR.DS-02, a missing header to PR.PS-01, a vulnerable library to ID.RA-01. - The CRA is mapped to Annex I. Known-vulnerable components, insecure defaults, weak transport, tracking pixels and attack surface each map to a specific requirement. What it can't do: Article 14's 24-hour and 72-hour reporting duties are processes, not scan findings, so nothing maps to them. And a web scan is supporting evidence for a product's CRA posture, not a conformity assessment. We'd rather say that up front. Full write-up in the first comment. Is the CRA on your radar yet, or still a 2027 problem? #CyberResilienceAct #NISTCSF #Compliance

A security scan and a compliance audit speak different languages. The scan says "missing Strict-Transport-Security header". The auditor asks "how do you protect data in transit, and can you show me?" Someone usually translates by hand, in a spreadsheet, the week before the audit. Compliance mapping automates that translation. Each technical finding is linked to the framework control it relates to, so you get two views: what is wrong, and which obligations it touches. Why teams use it: Less evidence-gathering and rewriting before an audit Gaps show up early, when several findings land on the same control Ready answers for customer security questionnaires and vendor reviews A record that builds over time instead of a once-a-year scramble Decloak maps findings to SOC 2, ISO 27001, NIS2, DORA, LGPD and PCI DSS v4.0. It is a Pro feature that runs on the scan you already do, with a tab per framework on the report and a Compliance Controls tile on your scoreboards. What it isn't: a certification. It is an indicative mapping, and a website scan can only see what is observable from outside. Policies, training, access reviews and vendor contracts are still on you. PCI DSS is assessed by a qualified assessor. Used honestly, it is a head start: the technical evidence, already sorted the way an auditor thinks. Full guide in the first comment. Which framework do your customers ask about most? #Compliance #SOC2 #ISO27001

AI writes code that compiles about 100% of the time. It still fails security tests in nearly half of tasks. Veracode's 2026 GenAI Code Security Report tracked more than 100 models across four snapshots. The average security pass rate is 56%. When tracking began it was 55%. A year of better models, longer context and stronger reasoning bought one percentage point. The details are the useful part: Coding-specific models averaged 51%, general-purpose models 52% Model size made no meaningful difference The top model, GPT-5.5, still fails about one security task in three SQL injection and weak crypto: 83% and 87% pass. Cross-site scripting: 15%. Log injection: 12% There are honest caveats. The tests ran against raw models, with no agents, guardrails or human review. So 56% is the rate at which models generate flaws, not the rate at which they reach production. But AI now writes roughly half of committed code, and the failure rate hasn't moved. Our read: treat AI-generated code like any unreviewed code, put extra review into output handling and XSS, and check what the deployed site actually exposes. We wrote up the full numbers, and what the report doesn't prove, in this week's Uncloaked digest (link in the first comment). How does your team review AI-written code before it ships? #AppSec #AICoding #VibeCoding

When we launched AI Pentesting, we listed what it couldn't do yet. SSRF, XXE and command injection were on that list. Today all three are confirmed with proof. AI Pentesting now runs seven tool-backed checks: sqlmap, dalfox, commix, nuclei out-of-band for SSRF and XXE, ffuf, nuclei exposure templates and jwt_tool. Each one runs in an isolated sandbox and only reports "confirmed" with reproducible evidence. SSRF and XXE are the interesting ones. Often nothing comes back in the response to prove them, so we test out of band: the probe asks your server to contact a canary address we control. If your server makes that call, the vulnerability is real. What else changed: It tests far more of each site: every parameterised URL from the crawl, the API calls your pages make, discovered endpoints, and a larger list of common auth and API paths across the major stacks It works on single-page apps, reading API endpoints directly from Angular, React and Vue bundles. Against OWASP Juice Shop, the full scan now discovers the API and confirms a real SQL injection Better tool defaults, so real injections the old settings missed are now caught Confirmed exploits now lower your overall Security Score, and the scan email waits for the final results Roughly five times fewer sandboxes per scan, with the same coverage What it still doesn't do: CSRF, or access control bugs such as IDOR. And it doesn't replace a formal pentest when a contract or regulator asks for one. Full write-up in the first comment. Which vulnerability class would you most like to see confirmed automatically? #Pentesting #AppSec #DevSecOps

A scanner tells you something looks wrong. A penetration test tells you it is exploitable. Most teams only get the first one, and have to guess at the second. We wrote a plain-language guide to AI pentesting: what it is, who it is for, and what it can't do yet. The short version: - Scanning observes and flags. It is fast and broad, and it produces false positives. - Pentesting attacks and reports what worked, with evidence. It is trustworthy, but slow and costly. - AI pentesting automates the "try it and see" step in between, so a finding moves from "might be exploitable" to "here is the request and response that proved it". How Decloak's version works: a fixed toolkit of real tools (sqlmap, dalfox, ffuf, nuclei and jwt_tool), not an AI improvising attacks. Every target comes from a finding the scan already produced. Each run happens in a fresh sandbox with network access limited to the one domain under test, and a second consent checkbox is required before anything runs. Where it falls short, because it matters: it confirms SQL injection and XSS with proof. It doesn't yet cover SSRF, XXE, CSRF, IDOR or several other classes. It is continuous confirmation between human-led tests, not a substitute if a customer or regulator requires one. It is most useful for teams that ship often, don't have a security team, build with AI tools, or need evidence for customers and auditors. Full guide in the first comment. When a scan flags something, how do you decide whether it is real? #Pentesting #ApplicationSecurity #DevSecOps

We've redesigned our homepage, because Decloak has evolved. We launched as a free scanner: paste a URL, get a scored security report in about 15 seconds. That's still there, and it's still free. But the platform has grown well beyond it. Today Decloak includes: - An AI agent that investigates your whole site and shows its reasoning - AI pentesting that attempts real exploitation in a sandbox, with proof for every confirmed finding - Checks aimed at AI-built apps, like open Supabase databases and leaked keys - Findings mapped to SOC 2, ISO 27001, NIS2, DORA, LGPD and PCI DSS, with audit-ready evidence The old site undersold all of that. It looked like a scanner, and we've become a security platform. So we rebuilt the homepage to show it, starting from a simple idea: your site isn't just what visitors see, it's everything running underneath. Come and see for yourself. Run a free scan on your own site, or watch the new film on the homepage. https://decloak.dev #cybersecurity #pentesting #appsec #compliance

A customer said this about Decloak: "This Is One of the Most Impressive Security Tools I’ve Seen on AppSumo!" Another said: "... I really love this tool! Thank you for shipping it to us!" We ship features the community asks for, tracked on a members-only roadmap. We just launched an expansion to our AI pentesting feature, and recently launched "expert mode" for cybersecurity pros. The lifetime deal is live on AppSumo. Link in the first comment.

Two ways to sign in to Decloak, and a batch of fixes we're glad to be shipping. New: sign in with Microsoft (personal and Microsoft 365 work accounts) or GitHub. Security teams and developers already live in those accounts, usually behind SSO and MFA, so it is easier and safer than creating another password. We never see or keep your password or the provider's token. Then the part we found most interesting. A long-standing Playwright bug, thrown from inside the library itself, was crashing our worker when a page added iframes quickly. Because one process ran every queue, a single bad page took down every scan running at the same moment. Autoplaying YouTube and Vimeo embeds were the trigger. What we did: contained the crash, built a reproduction harness, made retries safe so we never duplicate findings, and blocked video player iframes on every scan. We also fixed accuracy problems raised customers who sent us feedback: - Patched sites being read as "WordPress 2" with hundreds of CVEs - Scripts delayed by caching plugins never loading in our scanner - A HubSpot false positive - Unreachable sites getting an A instead of "we couldn't reach this site" Thank you to everyone who tells us when a result looks wrong. It is the fastest way we improve. Full write-up in the first comment. If a scanner can't reach your site, what should it report? #WebSecurity #Reliability #ProductUpdate

A company that sells identity theft protection got breached by a phone call. Aura, an identity protection and credit monitoring company, disclosed a breach affecting roughly 900,000 records. The entry point wasn't technical at all, an employee handed over account access during a targeted voice phishing call. ShinyHunters claimed responsibility. Every layer of technical security in the world doesn't close a gap that opens when a person on the phone is convinced to do the wrong thing, and there's a real irony in exactly whose product exists to prevent this. Separately, Trezor's vendor breach, which we covered a few weeks ago, kept escalating. First, 67,000 more customers were exposed because their shipping vendor had kept data it was contractually required to delete. Then attackers breached Trezor's email provider and used it to send phishing emails to 347,000 addresses, fake "critical security alert" messages that looked exactly like a genuine breach notification, weaponizing the very trust a real security alert depends on. Around 2,500 people clicked. And KDDI, a major Japanese telecom, disclosed a breach exposing up to 14.2 million email addresses and passwords, caused by a vulnerability in third-party software inside a single shared email platform serving six separate ISPs. None of these are new attack techniques. All three are reminders that the weakest link is rarely the thing you're actively monitoring. (Full roundup with sources in the comments) #WebSecurity #Phishing #DataBreach

A browser shows a padlock and most people stop thinking about it there. But "the certificate hasn't obviously failed" and "the connection is actually well configured" are two very different bars, and four separate things underneath that one icon can each go wrong independently. Expiry is the one everyone already knows, loud, unmissable, but still catches organisations out because renewal automation breaks silently more often than people expect. Chain validation is invisible until it breaks for the wrong client, most modern browsers quietly patch an incomplete chain using cached intermediates, but older browsers and API clients often don't, and the connection just fails with no obvious explanation. Protocol version matters more than people assume, TLS 1.0 and 1.1 are formally deprecated and still accepted more often than you'd think. And cipher strength is the one almost nobody checks manually, because unlike an expired cert, there's no browser warning for a weak cipher suite. A certificate can be freshly issued, correctly chained, and still served over a deprecated protocol with a weak cipher. Still shows the padlock. Still fails a real security review. We check all four automatically on every scan, expiry with actual runway shown, chain validation, protocol version, and cipher strength, every check shown including the ones that pass. Would you have guessed your own site's certificate is fine on all four, or just the one that throws a warning? (Full breakdown in the comments) #TLS #SSL #WebSecurity