consolidation of some of the modules, localization fixes, product advisories work, qa work

2026-03-05 03:54:22 +02:00
parent 7bafcc3eef
commit 8e1cb9448d
3878 changed files with 72600 additions and 46861 deletions
--- a/docs-archived/product/advisories/2026-02-28
+++ b/docs-archived/product/advisories/2026-02-28
@@ -0,0 +1,42 @@
+I’m sharing this because the current state of runtime security, VEX maturity, and SBOM/attestation tooling is *actively shaping how buyers prioritize verifiable evidence over vendor claims* — and the latest product releases and community discussions show real gaps you should be tracking.
+
+When vendors talk about **runtime protection and exploitability insights**, the focus is increasingly on live telemetry, threat detection, and *actionable blocking*, but the specifics vary in documentation and implementation.
+
+![Image](https://www.datocms-assets.com/75231/1728918689-sensor-attack.gif)
+
+![Image](https://cdn.prod.website-files.com/681a1c8e5b6ebfc0f8529533/689cbeac169e6f38021203c0_monitor-cost.png)
+
+![Image](https://www.securecodebox.io/assets/images/2023-09-15-depencytrack-projects-6458c7f735d045c0780725a63f52be21.png)
+
+![Image](https://opengraph.githubassets.com/0edbec120b6b051cfc92d3f1ef68e3779e92b8b5c3d86b048b2a334b3492284a/aquasecurity/trivy/discussions/10094)
+
+**1) Runtime exploitation & blocking — vendors pushing real-time, but evidence varies**
+Wiz’s runtime sensor for Windows and cloud-native workloads is positioned around *real‑time threat detection, execution context, and blocking* of suspicious behaviors across containers, VMs, and hybrid environments — framing runtime as a *last line of defense* with hybrid file integrity monitoring and automated responses. ([wiz.io][1])
+Sysdig’s recent release notes focus on *runtime vulnerability scanning, “in‑use” spotlighting of active vulnerabilities,* and enhancements like cloud response actions in their threat detection feed, but explicit exploitability blocking is handled via policy/risk mechanisms rather than a singular “block here” narrative. ([Sysdig Documentation][2])
+
+This reinforces a practical buyer theme: *raw runtime telemetry + reproducible blocking artifacts* matter more than UI screenshots alone when evaluating exploitability claims.
+
+**2) VEX / OpenVEX tooling is still “experimental” in major scanners**
+Trivy’s documentation still labels VEX support as **experimental**, outlining only basic filtering based on SBOM and VEX documents. ([Trivy][3])
+Real community issues — like Trivy not suppressing multiple VEX statements for the same CVE when PURLs differ, or tools ignoring OpenVEX at ingestion time — highlight *edge‑case gaps* in practical suppression workflows. ([GitHub][4])
+
+For procurement, that means *test vectors and compliance scripts* should include VEX corner cases vendors rarely document.
+
+**3) Signing and attestation practices are evolving but not yet commodity**
+Industry guidance (e.g., the emerging VeriSBOM research) emphasizes *cryptographically verifiable SBOM assertions using zero‑knowledge proofs*, selective disclosure, and trustless validation.
+Meanwhile, projects like Chainguard and cosign are promoting SBOM signing recipes and Rekor logs as artifacts, but the *evidence of vendor support (signed DSSE envelopes + inclusion proofs) isn’t broadly published in recent release notes.*
+
+**Why this matters right now**
+
+* Runtime claims without *signed evidence or API artifacts* leave buyers unable to prove exploitability coverage in audits.
+* VEX tooling is improving but still fails on real-world suppression edge cases.
+* Attestation infrastructure (DSSE + Rekor) is available; what’s missing is *standardized published artifacts* vendors can point to in procurement benchmarks.
+
+You’re seeing exactly where **procurement acceptance criteria can force conversion of vendor claims into verifiable artifacts** rather than promises. This matters when evaluating CNAPP/CWPP platforms and asking vendors for reproducible evidence — not just UI screenshots or blog posts.
+
+If you want, I can point you to specific RFCs, SBOM/VEX test cases, and trivy/Grype output examples showing these gaps in action.
+
+[1]: https://www.wiz.io/blog/wiz-runtime-sensor-for-your-windows-environment?utm_source=chatgpt.com "Cloud-native Security for your Windows environment"
+[2]: https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/?utm_source=chatgpt.com "SaaS: Sysdig Secure Release Notes"
+[3]: https://trivy.dev/docs/v0.51/supply-chain/vex/?utm_source=chatgpt.com "VEX"
+[4]: https://github.com/aquasecurity/trivy/discussions/7885?utm_source=chatgpt.com "CycloneDX VEX: Trivy fails to suppress all findings when ..."