Skip to content

Commit fe2536c

Browse files
mdabir1203mdabir1203
authored
Merge branch 'main' into codex/develop-supply-chain-integrity-framework2025-11-01-5ob3nl
2 parents 49b7325 + 7291e51 commit fe2536c

2 files changed

Lines changed: 95 additions & 6 deletions

File tree

‎.github/workflows/slsa-release.yml‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -186,6 +186,7 @@ jobs:
186186
base64-subjects: ${{ needs.primary-build.outputs.subjects }}
187187
provenance-name: ${{ needs.primary-build.outputs.artifact_name }}.intoto.jsonl
188188
upload-assets: true
189+
189190
secrets: inherit
190191

191192
publish:

‎README.md‎

Lines changed: 94 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,6 @@
22

33
ShadowMap is a Rust toolkit for mapping exposed assets, confirming risky services, and exporting clear recon results.
44

5-
---
65

76
## Quick start
87

@@ -28,7 +27,31 @@ cargo clippy --workspace --all-targets -- -D warnings
2827
cargo test --workspace
2928
```
3029

31-
---
30+
### Performance Profiling & Hotpath CI
31+
32+
**Issue tree (why the `hotpath-profile` workflow failed):**
33+
34+
- GitHub Action error: `no example target named 'benchmark'`
35+
- Workflow command: `cargo run --example benchmark --features='hotpath,hotpath-ci'`
36+
- Repository state: no `examples/benchmark.rs` instrumented for Hotpath
37+
- Outcome: profiling metrics were never emitted, so the workflow aborted before collecting JSON baselines
38+
39+
With the new `examples/benchmark.rs` workload in place the workflow can build deterministic profiling metrics again. You can replay the job locally with the same steps the Action runs:
40+
41+
1. **Timing profile**
42+
```bash
43+
cargo run --example benchmark --features='hotpath,hotpath-ci' | grep '^{"hotpath_profiling_mode"'
44+
```
45+
2. **Allocation profile** (mirrors the CI's second check)
46+
```bash
47+
cargo run --example benchmark --features='hotpath,hotpath-ci,hotpath-alloc-count-total' \
48+
| grep '^{"hotpath_profiling_mode"'
49+
```
50+
3. **Interpret the JSON output** – Each run prints a DS-like payload keyed by `hotpath_profiling_mode`, listing function metrics captured from the synthetic ShadowMap pipeline (enumeration, TLS parsing, fingerprint normalization, etc.). The workflow artifacts stash both the head and base JSON blobs so regressions are easy to spot.
51+
52+
### Landing page, billing checkout & Vercel
53+
54+
ShadowMap now includes a minimalist, luxury-inspired landing page that mirrors the in-app experience. The Rust server renders it dynamically with localized pricing and optional Stripe checkout, while a static export in `landing-page/index.html` is ready for Vercel hosting.
3255

3356
## Profiling benchmark
3457
The Hotpath CI workflow expects an example benchmark. You can replay the same workload locally to confirm profiling data is produced:
@@ -41,8 +64,19 @@ Add `hotpath-alloc-count-total` to the feature list if you also need allocation
4164

4265
---
4366

44-
## Secure release pipeline (step by step)
45-
ShadowMap ships with a reproducible release pipeline that follows the SLSA guidance. Each release tag runs the jobs below in order:
67+
ShadowMap now ships a SLSA-ready, reproducible release system that elevates the earlier SBOM scan into an end-to-end provenance chain. The architecture, mission, and operational guardrails are captured in [`docs/security/slsa-ready-pipeline.md`](docs/security/slsa-ready-pipeline.md), while [`docs/security/verify.md`](docs/security/verify.md) teaches consumers how to validate each release.
68+
69+
#### Step-by-step secure release flow
70+
71+
1. **Signed commits & tags** – Developers sign commits, cut an annotated tag, and push to GitHub. The [`slsa-release`](.github/workflows/slsa-release.yml) workflow starts automatically for `v*` tags.
72+
2. **Primary hermetic build** – The `primary-build` job pins toolchains, fetches dependencies with `--locked`, disables outbound networking, compiles the binaries, and produces SBOM + checksum manifests.
73+
3. **Independent rebuild** – `reproducibility-build` repeats the process on a separate runner to generate a second checksum manifest.
74+
4. **Determinism check** – `compare-builds` downloads both manifests and performs a byte-for-byte diff. Any mismatch fails the release.
75+
5. **Provenance generation** – Once the checksums match, the reusable `slsa-github-generator` workflow emits a DSSE attestation that records the workflow run, materials, and artifact digest.
76+
6. **Keyless signing & publishing** – The `publish` job signs the attestation with cosign keyless OIDC credentials, bundles the `.intoto.jsonl` + `.sig` + SBOM + binaries, and uploads everything to the GitHub Release.
77+
7. **Consumer verification** – Operators download the release bundle and run `./scripts/verify_release.sh` to validate the signature, provenance, checksum, and SBOM in one command.
78+
79+
For day-to-day SBOM inspection or CI gating you can still run the lightweight scan locally:
4680

4781
1. **Primary hermetic build** – Pin the toolchain, fetch locked dependencies, disable outbound network access, and build the release binaries plus SBOM and checksums.
4882
2. **Independent rebuild** – Run the same steps on a second runner to generate another checksum set.
@@ -62,9 +96,63 @@ The full architecture, controls, and reasoning live in [`docs/security/slsa-read
6296
```
6397
3. The script performs signature, provenance, checksum, and SBOM validation. Any failure exits with a non-zero status so it can be wired into automation.
6498

65-
Consumers who prefer manual checks can review [`docs/security/verify.md`](docs/security/verify.md).
99+
For repeatability you can run `./scripts/security-scan.sh` which wraps the SBOM generation and Grype scan with sensible defaults,
100+
while `./scripts/verify_release.sh` handles the full attestation verification for published releases.
66101

67-
---
102+
### Data Security & Compliance
103+
104+
ShadowMap aligns its operational safeguards with SOC 2 Trust Services Criteria and GDPR privacy requirements. The
105+
[Data Security and Compliance Strategy](docs/data-security.md) describes the control owners, evidence expectations, and
106+
validation activities that keep reconnaissance data secure throughout its lifecycle.
107+
108+
### Social intelligence-driven security automation
109+
110+
Teams layering social listening on top of ShadowMap can adopt the
111+
[Social Intelligence Insights for Security](docs/social-intelligence-security.md) guide. It explains how the Codex
112+
agent configuration transforms emerging chatter into normalized signals, correlates them with known assets, and drives
113+
guardrailed remediation playbooks.
114+
115+
The framework now runs those social intelligence stages natively during every autonomous scan. Normalized mentions are
116+
correlated with live assets, exported alongside the technical report, and surfaced in the interactive dashboard so
117+
teams can immediately see high-signal chatter, affected hosts, and recommended responses. Override the baked-in Codex
118+
plan by setting `SHADOWMAP_SOCIAL_CONFIG=/path/to/framework.yaml` before launching a run to load a custom orchestration
119+
file without recompiling.
120+
121+
### Technical report automation
122+
123+
Run `./scripts/generate-technical-report.sh` to materialize the latest reconnaissance brief as `build/technical-report.md`.
124+
The [Generate technical report PDF workflow](.github/workflows/generate-technical-report-pdf.yml) wires this script into the
125+
CI pipeline and uses Pandoc to emit a downloadable artifact—trigger it manually from the **Actions** tab whenever you need a
126+
fresh PDF without committing binaries.
127+
128+
### Application Governance & Resilience
129+
130+
Teams that need to spot unapproved apps, fragmented data flows, or silent system failures can extend ShadowMap's
131+
discoveries into governance and reliability workflows using the
132+
[Application Governance Integration guide](docs/app-governance-integration.md). It outlines how to fuse ShadowMap outputs
133+
with CMDBs, data lineage tools, and observability platforms to close monitoring gaps.
134+
135+
### Organizational Adoption Playbook
136+
137+
Security programs that want to operationalize ShadowMap across large enterprises can follow the
138+
[Organizational Adoption Playbook](docs/org-adaptation.md). It lays out governance structures, stakeholder roles, and
139+
business metrics that translate reconnaissance coverage into measurable risk reduction and executive-aligned value.
140+
141+
### Automated security workflow
142+
143+
The repository ships with a dedicated GitHub Action located at [`.github/workflows/security-scan.yml`](.github/workflows/security-scan.yml). It installs `cargo-cyclonedx` and `grype`, generates `shadowmap-bom.json`, scans it for vulnerabilities, and uploads the SBOM plus a JSON report as build artifacts. The workflow runs automatically for pull requests and pushes to `main`, and can also be started manually from the **Actions** tab via the **Run workflow** button.
144+
145+
### Desktop GUI (optional)
146+
```bash
147+
cargo run --features gui --bin shadowmap-gui
148+
```
149+
Enter a target domain in the GUI and select **Run Scan**; results are written to the output directory displayed on completion. The interface is implemented entirely in Rust via [`iced`](https://github.com/iced-rs/iced).
150+
151+
### Slint dashboard preview (experimental)
152+
```bash
153+
cargo run --features dashboard --bin shadowmap-dashboard
154+
```
155+
Use the Slint-powered dashboard to launch scans, review live status messages, and visualize summaries of subdomain activity and alert categories.
68156

69157
## Additional documentation
70158
- [`docs/data-security.md`](docs/data-security.md) – Data security controls and compliance notes.

0 commit comments

Comments
 (0)