From 30d28641a59cb79b631996be22b8158df72df6d0 Mon Sep 17 00:00:00 2001 From: O M Date: Wed, 14 Oct 2026 18:47:57 -0400 Subject: [PATCH 1/2] Document Phase 4 and Phase 5 next to the shipped collectors. The docs site still described Phase 3 as the end of the roadmap. These pages name the planned package inventory and the secret and malware findings that follow it. Co-authored-by: Cursor --- .../blog/open-source-cspm-cnapp-tools-2026.md | 2 +- src/pages/docs/architecture.astro | 10 +++++++++- src/pages/docs/collectors/aws.astro | 5 ++++- src/pages/docs/collectors/azure.astro | 5 ++++- src/pages/docs/collectors/gcp.astro | 7 +++++-- src/pages/docs/collectors/index.astro | 17 +++++++++++++++++ src/pages/docs/collectors/kubernetes.astro | 3 ++- src/pages/docs/enrichment.astro | 3 +++ src/pages/docs/index.astro | 3 +++ src/pages/docs/open-source.astro | 12 ++++++++++-- 10 files changed, 58 insertions(+), 9 deletions(-) diff --git a/src/content/blog/open-source-cspm-cnapp-tools-2026.md b/src/content/blog/open-source-cspm-cnapp-tools-2026.md index eff480d..3af0cae 100644 --- a/src/content/blog/open-source-cspm-cnapp-tools-2026.md +++ b/src/content/blog/open-source-cspm-cnapp-tools-2026.md @@ -69,7 +69,7 @@ The differentiator for **self-hosted CNAPP**-like experiences is the **security | Finding enrichment | CVEs and misconfigs on graph nodes | | Path queries | Prioritize by attack path, not severity | -**[OpenSourceOM](/prowler-alternative/)** is that layer, self-hosted and Apache-2.0: collectors, a Postgres graph, and CSPM rules scored by path. [Prowler vs OpenSourceOM](/prowler-alternative/) is the Prowler alternative comparison. Cartography and BloodHound are on [self-hosted CNAPP](/self-hosted-cnapp/). Phase 3 has shipped — see the [roadmap on GitHub](https://github.com/OpenSourceOM/core/blob/main/docs/ROADMAP.md). +**[OpenSourceOM](/prowler-alternative/)** is that layer, self-hosted and Apache-2.0: collectors, a Postgres graph, and CSPM rules scored by path. [Prowler vs OpenSourceOM](/prowler-alternative/) is the Prowler alternative comparison. Cartography and BloodHound are on [self-hosted CNAPP](/self-hosted-cnapp/). Phase 3 has shipped. Phase 4 (package inventory from persistent workload storage) and Phase 5 (secret and malware findings on that storage) are next — see the [roadmap on GitHub](https://github.com/OpenSourceOM/core/blob/main/docs/ROADMAP.md). ## Proprietary CNAPP vs. open source stack diff --git a/src/pages/docs/architecture.astro b/src/pages/docs/architecture.astro index 959744a..98668e5 100644 --- a/src/pages/docs/architecture.astro +++ b/src/pages/docs/architecture.astro @@ -36,6 +36,8 @@ import DocsLayout from '@/layouts/DocsLayout.astro'; internal/rules, and the collectors. PostgreSQL is the graph store. Phase 3 adds the plugin SDK, the embedded rule pack, a Helm chart, and cloud audit context from CloudTrail, Activity Log, and Admin Activity logs, on top of the Phase 2 feature set. + Phase 4 and Phase 5 are planned: package identifiers from persistent workload storage, + then secret and malware findings on that same storage. They are not in this layout yet. 

{`Cloud / Kubernetes APIs
         │
@@ -121,7 +123,13 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
   
What this version leaves out

   

     Multi-tenant RBAC, SAML, and platform audit logs of who clicked what in the console are
-    outside the open source core. See Open source scope.
+    outside the open source core, as is classification of object bodies and database rows.
+    See Open source scope.
+    Phase 4 will write packages from root volumes, boot images, container layers,
+    function bundles, and shared filesystems. Phase 5 will add secret and malware findings
+    on that storage, recording the kind and the path. Neither phase is implemented.
+    om scan aws, om scan azure, and om scan gcp stay
+    read-only API scans.
     Recursive path SQL is capped. Azure and GCP REACHABLE edges still ignore
     firewalls; the collector pages describe that and the IAM rules behind CAN_ACCESS.
     The design notes in the core repo
diff --git a/src/pages/docs/collectors/aws.astro b/src/pages/docs/collectors/aws.astro
index bf25f3d..d9769af 100644
--- a/src/pages/docs/collectors/aws.astro
+++ b/src/pages/docs/collectors/aws.astro
@@ -96,7 +96,10 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
     API reports no further page.
   

   

-    The collector does not inventory Lambda, EKS, VPCs, or IAM groups. RDS and Aurora instances are
+    The collector does not inventory Lambda, EKS, VPCs, or IAM groups, and it does not snapshot
+    EBS volumes or read packages on disk. That inventory is Phase 4 on the
+    roadmap, as a
+    separate opt-in scan. RDS and Aurora instances are
     datastores, and their tags supply sensitivity the same way a bucket tag does.
     Buckets are listed
     account-wide. EC2 and security groups are the one region in AWS_REGION.
diff --git a/src/pages/docs/collectors/azure.astro b/src/pages/docs/collectors/azure.astro
index 3ef1811..887295d 100644
--- a/src/pages/docs/collectors/azure.astro
+++ b/src/pages/docs/collectors/azure.astro
@@ -144,6 +144,9 @@ az login
     built-in set above. A subscription Reader covers the ARM calls, including
     Microsoft.Insights/eventtypes/values/read. Listing containers also needs
     Microsoft.Storage/storageAccounts/blobServices/containers/read. The collector
-    does not call mutating APIs.
+    does not call mutating APIs, and it does not snapshot OS disks or read packages on the VM.
+    That inventory is Phase 4 on the
+    roadmap, as a
+    separate opt-in scan.
   

 
diff --git a/src/pages/docs/collectors/gcp.astro b/src/pages/docs/collectors/gcp.astro
index bf5ae4e..3826625 100644
--- a/src/pages/docs/collectors/gcp.astro
+++ b/src/pages/docs/collectors/gcp.astro
@@ -151,7 +151,10 @@ gcloud auth application-default login
     The scan lists instances, firewalls, load-balancer pieces, buckets, bucket IAM, service
     accounts, the project IAM policy, Cloud SQL instances, and Admin Activity log entries.
     Listing those entries needs logging.logEntries.list. Logs Viewer
-    (roles/logging.viewer) includes it. The collector does not call mutating APIs
-    and does not request Data Access logs.
+    (roles/logging.viewer) includes it. The collector does not call mutating APIs,
+    does not request Data Access logs, and does not snapshot boot disks or read packages on the
+    instance. That inventory is Phase 4 on the
+    roadmap, as a
+    separate opt-in scan.
   

 
diff --git a/src/pages/docs/collectors/index.astro b/src/pages/docs/collectors/index.astro
index 52fd109..4001378 100644
--- a/src/pages/docs/collectors/index.astro
+++ b/src/pages/docs/collectors/index.astro
@@ -134,4 +134,21 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
     queries have a start vertex. Plugins that want internet paths must include that node
     themselves. The id constant is internet:global in sdk/collector.
   

+
+  
What a scan does not read

+  

+    Built-in collectors call cloud APIs. They do not snapshot a root volume, pull container
+    layers, or download a function bundle. om scan aws stores an AMI id on
+    image. om scan k8s stores image references. Neither writes the
+    packages inside. om enrich cve can match a CVE only when packages
+    is already on the workload, which today means the demo graph or a plugin.
+  

+  

+    Phase 4 on the
+    roadmap
+    is that inventory, from root volumes, boot images, container layers, function bundles, and
+    shared filesystems. It will be a separate opt-in scan, because a volume snapshot is a write
+    in the account. The API scans on this page stay read-only. Phase 5 then records a secret
+    or malware finding from storage that scan already opened, storing the kind and the path.
+  

 
diff --git a/src/pages/docs/collectors/kubernetes.astro b/src/pages/docs/collectors/kubernetes.astro
index 343c9c3..b9bb478 100644
--- a/src/pages/docs/collectors/kubernetes.astro
+++ b/src/pages/docs/collectors/kubernetes.astro
@@ -27,7 +27,8 @@ export K8S_NAMESPACE=payments
     services, and service accounts. Deployments and ReplicaSets are not nodes. Pods are the
     workloads. Each pod stores images: the sorted, unique image refs from its init
     containers and app containers. Ephemeral containers are omitted. An empty image list is not
-    written.
+    written. The refs are not pulled, so packages inside the layers are absent until Phase 4
+    on the roadmap.
   

 
   
Mapping

diff --git a/src/pages/docs/enrichment.astro b/src/pages/docs/enrichment.astro
index 2436be9..31fbf02 100644
--- a/src/pages/docs/enrichment.astro
+++ b/src/pages/docs/enrichment.astro
@@ -44,6 +44,9 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
     om scan aws writes image as the AMI id when the instance has one.
     A plugin can set packages directly. See
     Plugins.
+    Phase 4 will fill packages from persistent workload storage (root volumes, boot
+    images, image layers, function bundles, and shared filesystems). Enrichment stays a matcher.
+    See the roadmap.
   

 
   
NVD

diff --git a/src/pages/docs/index.astro b/src/pages/docs/index.astro
index 0af35d0..40c5d3f 100644
--- a/src/pages/docs/index.astro
+++ b/src/pages/docs/index.astro
@@ -38,6 +38,9 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
     into PostgreSQL. Named path queries, CSPM rules, and CVE enrichment rank what an outsider can
     reach. These pages describe the om CLI, REST API, and collectors as they ship in
     OpenSourceOM/core. Phase 3 has shipped.
+    Phase 4 and Phase 5 are open on the
+    roadmap:
+    package inventory from persistent workload storage, then secret and malware findings on that storage.
   

 
   
Start

diff --git a/src/pages/docs/open-source.astro b/src/pages/docs/open-source.astro
index 4a47d75..6cdf7ac 100644
--- a/src/pages/docs/open-source.astro
+++ b/src/pages/docs/open-source.astro
@@ -16,7 +16,7 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
     {
       question: 'What is outside the open-source core?',
       answer:
-        'Insider-threat analysis, SAML and SSO, multi-tenant RBAC, and audit logs of who used the console are planned outside the open-source core. Attack paths, CSPM, collectors, and the self-hosted API stay in core.',
+        'Insider-threat analysis, SAML and SSO, multi-tenant RBAC, audit logs of who used the console, and classification of object bodies and database rows are planned outside the open-source core. Attack paths, CSPM, collectors, workload package inventory, and the self-hosted API stay in core.',
     },
   ]}
   related={[
@@ -83,6 +83,10 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
           Cloud audit ingest as graph context
           Immutable platform audit logs (who used OpenSourceOM)
         
+        
+          Workload package inventory (Phase 4) and secret or malware findings on that storage (Phase 5)
+          Classification of object bodies and database rows
+        
       
     
   
@@ -93,6 +97,8 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
     exposed path. Path queries return those events with the path. Data Access logs are not
     collected. Platform audit logs — operator actions in the
     console/API, SSO identity, retention, and auditor export — belong in the commercial offering.
+    Phase 4 and Phase 5 stay in core: packages, secrets, and malware on storage an outsider can
+    reach. Reading object bodies and database rows to classify customer data does not.
   

 
   
Why this split

@@ -113,7 +119,9 @@ import DocsLayout from '@/layouts/DocsLayout.astro';
     CSPM rules, blast radius, Kubernetes ingest, exports, the collector plugin SDK,
     and the Helm chart are in the tree, along with inventory-backed CVEs, crown-jewel
     datastores, attack-path findings, and cloud audit context from CloudTrail, Activity Log,
-    and Admin Activity logs. How to run them is covered from
+    and Admin Activity logs. Phase 4 and Phase 5 are open and not in the tree yet: package
+    inventory from persistent workload storage, then secret and malware findings on that
+    storage. How to run what has shipped is covered from
     Getting started through
     Plugins. Commercial offerings are
     not available yet — there is no pricing, sales contact, or enterprise SKU

From 77c8a036489d829924b6a68c0ceb3b49ab0bdab2 Mon Sep 17 00:00:00 2001
From: O M 
Date: Wed, 14 Oct 2026 18:51:41 -0400
Subject: [PATCH 2/2] Bump the CSPM tools post lastmod after the roadmap edit.

Co-authored-by: Cursor 
---
 src/content/blog/open-source-cspm-cnapp-tools-2026.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/blog/open-source-cspm-cnapp-tools-2026.md b/src/content/blog/open-source-cspm-cnapp-tools-2026.md
index 3af0cae..d2b02d9 100644
--- a/src/content/blog/open-source-cspm-cnapp-tools-2026.md
+++ b/src/content/blog/open-source-cspm-cnapp-tools-2026.md
@@ -2,7 +2,7 @@
 title: "Open Source CSPM and CNAPP Tools in 2026: What Exists Today"
 description: "Survey of open source CSPM, self-hosted CNAPP alternatives, and graph-native cloud security tools in 2026 — plus how to evaluate self-hosted options for your team."
 pubDate: 2026-08-24
-updatedDate: 2026-10-13
+updatedDate: 2026-10-14
 author: OpenSourceOM Team
 tags:
   - open source CSPM