5/ It works on scans you already run. No setup needed. Full write-up: decloak.dev/journal/complian… Has anyone asked you about the CRA yet?

4/ What it can't do, plainly: The 24h and 72h reporting duties in Article 14 are processes, not scan findings, so nothing maps to them. A web scan is supporting evidence for the CRA, not a conformity assessment.

3/ The CRA is mapped to Annex I of the regulation. A known-vulnerable component maps to Part I (2)(a), insecure config to (2)(b), weak transport to (2)(e), tracking pixels to (2)(g), and attack surface to (2)(j).

2/ NIST CSF is mapped at subcategory level, because that's what questionnaires cite. "Protect" tells a reviewer nothing. - TLS issue: PR.DS-02 - Missing header: PR.PS-01 - Vulnerable library: ID.RA-01 - Unknown third-party script: GV.SC-07

1/ The EU Cyber Resilience Act's first obligations kicked in on 11 September. US vendor questionnaires keep asking about NIST CSF. Decloak now maps every scan finding to both. That's eight frameworks from one scan.

5/ The full guide, including use cases and limits: decloak.dev/journal/complian… Which framework do your customers ask about most?

4/ Decloak maps findings to SOC 2, ISO 27001, NIS2, DORA, LGPD and PCI DSS v4.0. It's a Pro feature that runs on the scan you already do. What it isn't: a certification. A website scan only sees what's observable from outside. Policies and processes are still on you.

3/ Why it's useful: - Less translation work before an audit - Gaps show up early, when several findings hit one control - Answers to customer security questionnaires - A record that builds over time, not just once a year

2/ Every framework is a list of controls. Mapping links each technical finding to the control it relates to. Instead of one flat list of issues, you get: - what's wrong - which obligations it touches

1/ A scan says: "missing Strict-Transport-Security header." An auditor asks: "How do you protect data in transit, and can you show me?" Someone has to translate. Compliance mapping does it automatically.

100%. The study shows that it actually doesn't matter what model you pick, the problem is the same - they still make the wrong security choices almost half of the time.

Generally we found less false positives in our AI pentesting feature, as it's using a very specific set of tools, and it only acts on endpoints and potential vulnerable URLs found by the agent during a security audit. So it's not blindly trying to test everything without guidance!

thank you! We really love the new look!

Thank you for the feedback! Let me know if you have the chance to test it.

Thank you!

5/ Our take: treat AI-written code as unreviewed code, and check what actually ships. Full breakdown, including what the report doesn't prove: decloak.dev/journal/uncloake… Is AI-written code reviewed differently on your team?

4/ Fair caveat: Veracode tested raw models, with no agents, guardrails or human review. So 56% is how often models generate flaws, not how often flaws reach production. But AI now writes roughly half of committed code, and the failure rate has held steady.

3/ Where models fail most: SQL injection: 83% pass Weak crypto: 87% pass Cross-site scripting: 15% pass Log injection: 12% pass XSS is one of the most common web bugs there is. The models barely register it.

2/ The details are worse than the average: - Coding-specific models: 51% - General-purpose models: 52% - Model size made no real difference - The best model (GPT-5.5) still fails about 1 in 3 security tasks

1/ AI models now write code that compiles about 100% of the time. They still fail security tests in nearly half of tasks. Veracode tracked 100+ models for a year. The average pass rate moved from 55% to 56%.