Record Phase 4 and Phase 5 on the roadmap

CONTRIBUTING.md

@@ -24,7 +24,7 @@ On a PR you can comment `@coderabbitai review` (incremental) or `@coderabbitai f
 
 ## Development guidelines
 
-- Keep collectors **read-only** toward cloud accounts by default
+- Keep collectors **read-only** toward cloud accounts by default. The Phase 4 workload scan is the opt-in exception: it may create and delete snapshots in the account, and it stores package identifiers only
 - Document graph schema changes in `docs/`
 - Prefer small, reviewable PRs
 - Add tests for graph queries and normalization logic

README.md

@@ -21,7 +21,7 @@ OpenSourceOM Core is the platform behind [opensourceom.org](https://opensourceom
 
 Traditional scanners flood you with CVEs and misconfigurations. OpenSourceOM connects the dots — showing which findings sit on paths from the internet to your sensitive data and privileged identities.
 
-> **Status:** Phase 3 has shipped. Further rule packs stay open for contributors ([#10](https://github.com/OpenSourceOM/core/issues/10)). See the [roadmap](./docs/ROADMAP.md).
+> **Status:** Phase 3 has shipped. Phase 4 (workload package inventory) and Phase 5 (secret and malware findings on that storage) are open. Further rule packs stay open for contributors ([#10](https://github.com/OpenSourceOM/core/issues/10)). See the [roadmap](./docs/ROADMAP.md).
 
 ## Why this exists
 
@@ -162,6 +162,8 @@ Full documentation: [opensourceom.org](https://opensourceom.org) (docs at [opens
 | **1** | Attack path queries, CVE enrichment, web UI, Azure/GCP collectors |
 | **2** | CSPM rules, blast radius, K8s connector, exports |
 | **3** | Plugin SDK, Helm, embedded rule pack, demo graph, inventory-backed CVEs, crown-jewel datastores, attack-path findings, and cloud audit context (CloudTrail, Activity Log, Admin Activity). Shipped. |
+| **4** | Package inventory from persistent workload storage: root volumes, boot images, container layers, function bundles, shared filesystems. Open. |
+| **5** | Secret and malware findings on storage Phase 4 already opens. Kind and path only. Open. |
 
 Details: [docs/ROADMAP.md](./docs/ROADMAP.md)
 

docs/ARCHITECTURE.md

@@ -5,7 +5,7 @@ SPDX-License-Identifier: Apache-2.0
 
 # Architecture
 
-> **Status:** Phase 3 has shipped. The collector plugin SDK, Helm, the embedded rule pack, and cloud audit context from CloudTrail, Activity Log, and Admin Activity logs are in the tree, alongside Phase 2 CSPM rules, blast radius, Kubernetes ingest, and exports. Further rule packs stay open for contributors.
+> **Status:** Phase 3 has shipped. The collector plugin SDK, Helm, the embedded rule pack, and cloud audit context from CloudTrail, Activity Log, and Admin Activity logs are in the tree, alongside Phase 2 CSPM rules, blast radius, Kubernetes ingest, and exports. Phase 4 (package inventory from persistent workload storage) and Phase 5 (secret and malware findings on that storage) are open. Further rule packs stay open for contributors.
 
 ## Overview
 
@@ -82,6 +82,12 @@ Shipped, in this order:
 
 Further community rule packs (PCI and additional CIS mappings) stay open for contributors ([#10](https://github.com/OpenSourceOM/core/issues/10)).
 
-Issue links: [ROADMAP.md](./ROADMAP.md)
+## Phase 4 and Phase 5
+
+Planned, not in the tree. Phase 4 writes `packages` (CPE 2.3 names and package URLs) from persistent workload storage onto the workload node that enrichment already matches. The sources, in order, are AWS Linux root volumes, Azure VM and GCE root volumes, boot images, container image layers and function bundles, and shared filesystems (EFS, Azure Files, Filestore). The scan is opt-in. `om scan aws`, `om scan azure`, and `om scan gcp` stay read-only API collectors. The workload scan runs a worker in the account, and it stores package identifiers only.
+
+Phase 5 adds a finding for a secret pattern or a malware signature on storage that Phase 4 reader already opened. The finding stores the kind and the path. Object bodies and database rows are in neither phase.
+
+Issue links: [ROADMAP.md](./ROADMAP.md) ([#102](https://github.com/OpenSourceOM/core/issues/102) through [#108](https://github.com/OpenSourceOM/core/issues/108)).
 
 See the [website architecture page](https://opensourceom.org/docs/architecture/) for user-facing documentation.

docs/ROADMAP.md

@@ -58,9 +58,38 @@ The path, in order:
 
 The ordered path above is complete.
 
-## After Phase 3
+## Phase 4 — Workload inventory
 
-[#10](https://github.com/OpenSourceOM/core/issues/10) stays open for a contributor who wants another rule pack (PCI and additional CIS mappings). It does not reopen Phase 3.
+Phase 4 is open. Cloud collectors record the VM, its exposure, and its identity. They do not record the packages installed on it. `om enrich cve` already writes a finding when `packages` on a workload matches. This phase fills that property from persistent workload storage.
+
+The phase ends when a package found in that storage is a CVE finding on the workload the graph already stores. A block volume is the first source. Boot images, container image layers, function bundles, and shared filesystems are the rest.
+
+The scan is opt-in and separate from `om scan aws`, `om scan azure`, and `om scan gcp`. Those commands stay read-only. The workload scan runs a worker in the account and region, reads package metadata, and writes CPE 2.3 names and package URLs onto the existing workload. Snapshots and mounts are removed when the scan finishes, including when it fails. File contents stay on the storage.
+
+The path, in order:
+
+- [ ] **AWS Linux root volumes** — [#102](https://github.com/OpenSourceOM/core/issues/102)
+- [ ] **Azure VM and GCE root volumes** — the same walker, those snapshot APIs — [#103](https://github.com/OpenSourceOM/core/issues/103)
+- [ ] **Boot images** — an AMI and the Azure and GCE equivalents, scanned once and applied to instances launched from that image — [#104](https://github.com/OpenSourceOM/core/issues/104)
+- [ ] **Container image layers and function bundles** — layers for images already stored on Kubernetes workloads, plus Lambda deployment packages and the Azure and GCP equivalents. No volume attach — [#105](https://github.com/OpenSourceOM/core/issues/105)
+- [ ] **Shared filesystems** — EFS, Azure Files, and Filestore, when the application is installed there and a root-volume scan would miss it — [#106](https://github.com/OpenSourceOM/core/issues/106)
+
+Object bodies and database rows stay out. They are customer data, not the installed software. A public bucket or database is already an exposure finding from the API scan.
+
+## Phase 5 — Findings on inventoried storage
+
+Phase 5 starts after a Phase 4 reader has opened that storage. A secret pattern or a malware signature found there becomes a finding on the same workload. The graph stores the kind and the path. It does not store the secret or the file. The finding then ranks with the other findings on an internet-reachable workload.
+
+The path, in order:
+
+- [ ] **Secrets** — kind and path only — [#107](https://github.com/OpenSourceOM/core/issues/107)
+- [ ] **Malware** — signature name and path only — [#108](https://github.com/OpenSourceOM/core/issues/108)
+
+Object bodies and database rows stay out of this phase as well.
+
+## Alongside the phases
+
+[#10](https://github.com/OpenSourceOM/core/issues/10) stays open for a contributor who wants another rule pack (PCI and additional CIS mappings). It does not reopen Phase 3, and it is not Phase 4 or Phase 5.
 
 ## Open source vs. commercial
 
@@ -75,11 +104,14 @@ The free OSS core focuses on **defending against external attackers** — unders
 | Console admins via Google or GitHub login | Viewer and other non-admin roles |
 | Community collectors and rule packs | Enterprise compliance workflows |
 | 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 |
 
 Console login in the OSS core is email and password. Google and GitHub are optional. The first account is created from the setup form or `om admin create`, and later admins get a temporary password. Every signed-in account is an admin. A personal API token for scripts is created only when that admin asks for one. Bring-your-own identity providers stay commercial.
 
 Cloud provider audit APIs (for example CloudTrail) are Phase 3 graph context ([#33](https://github.com/OpenSourceOM/core/issues/33)): evidence of exposure and attack paths. **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 the open-source core: which packages, secrets, and malware sit on storage an outsider can reach. Classification of object bodies and database rows belongs with the commercial offering.
+
 This split keeps the OSS project useful for any team that needs graph-native **external** risk prioritization, while commercial offerings can address **internal** risk and enterprise deployment needs without bloating the core repo.
 
 ## How to influence the roadmap