OpenPulse — Software Ecosystem Intelligence

Watch what can change underneath your software.

OpenPulse is an evidence-first intelligence system that discovers meaningful changes in the open-source software ecosystem, establishes their identity and applicability, and produces machine-readable evidence about their potential impact on software dependencies.

From "What is happening in open source?" to "What is happening to MY software?"

OpenPulse is the Software Ecosystem Evidence Plane of the Ikarus AI Labs research programme on Evidence-Based Assurance for AI-Mediated Software Change — not an EOL monitor, not an AI security product.

Most security tools tell you when your dependencies have a vulnerability. OpenPulse watches for something different: what can change underneath your software. We monitor the open-source ecosystem for end-of-life, support and license changes, registry and distribution changes, ownership changes, breaking changes and other supply-chain signals — then map those changes to the dependencies you actually use. So instead of another giant list of things happening in open source, OpenPulse answers:

"Something changed upstream. Does it affect us?" — with evidence.

Know Your Agent. Know Your Dependencies.

OpenPulse is part of the Ikarus AI Labs research programme. SafeAI and OpenPulse are intentionally separate instruments — combined-model claims stay out of this repo until the joint experiment runs:

Question	Project	Answer
What can this AI agent do?	SafeAI — KYA, Know Your Agent	Agent capabilities, prompt risks, tool permissions
What does the software it creates depend on?	OpenPulse — KYD, Know Your Dependencies	Upstream change intelligence mapped to your dependencies

AI can introduce dependencies faster than humans can review them. OpenPulse helps you understand what those dependencies depend on — and what happens when the ecosystem underneath them changes. AI writes code fast. OpenPulse watches what that code depends on.

The problem we solve

In July 2025, Bitnami announced that effective 28 August 2025 its public docker.io/bitnami catalog would stop publishing versioned images: existing tags move to an unmaintained bitnamilegacy archive, the mainline goes latest-only community tier, and production use requires a Bitnami Secure Images subscription. Miss that one announcement and CI/CD pipelines, Helm releases, and production pulls break — with no CVE ever filed, so no scanner fires.

Bitnami is the pattern, not the exception:

Signal	Example	Covered by traditional SCA?
CVE	Critical vulnerability	✅
EOL / EOS	Node.js 18 unmaintained, support window ends	⚠️ partial
License change	OSS → restrictive/commercial	⚠️ partial
Distribution change	Registry/image deleted, tags moved	❌
Support change	Community → paid subscription	❌
Ownership / maintainer change	Project acquired, maintainer leaves	❌
Repo health collapse	Activity dies, releases stop	⚠️ partial
Breaking roadmap	Major incompatible release	⚠️ partial
AI selection risk	Coding agent picks an obsolete package	❌

Every row above is a production incident waiting for a team that only watches CVEs.

Intelligence, not aggregation

A report item should demonstrate intelligence, not repeat news. Not:

Redis — EOL approaching.

But:

Redis 7.x — support lifecycle change detected Evidence: official lifecycle information · Potential impact: organisations running affected versions · Recommended attention: migration planning

That is the bar for every OpenPulse event: what changed, the evidence, who may be affected, and what to investigate.

One product, progressively more personal

Level	Customer question	OpenPulse answer	Status
Free	"What is happening in OSS?"	Monthly OSS Dependency Risk Report — first edition: September 2026 (100 projects, every item sourced)	✅ Shipped
Intelligence	"What is changing in the OSS projects I care about?"	OSS Dependency Intelligence — this repo	🔨 Building now
Early Warning	"What is changing in MY dependencies?"	Dependency Early Warning — watchlist + impact matching (openpulse check, scheduled runs)	Early preview
AI-native	"What dependencies is AI introducing?"	AI Supply Chain Governance — Know Your Dependencies	Direction

The metric that matters: Early Warning Lead Time

Repositories monitored is a vanity metric. The commercially meaningful one is:

Early Warning Lead Time — time between OpenPulse detecting a material upstream change and that change producing an observable impact on the customer's environment.

"Detecting" means first trustworthy detection (first_detected_at), never the latest re-observation; unknown first detection means no lead-time claim. The goal: "We identified an upstream change 47 days before it affected the customer's pipeline." We will not publish an average until independently measured customer incidents make it defensible — until then, verified case studies (Bitnami first).

What OpenPulse does

Upstream world                      OpenPulse engine                    You
GitHub releases ─┐                    ┌───────────────┐
OSV / NVD / CVE ─┼─ collectors ─────▶ │ Change Analyst │── findings ──┐
CISA KEV ────────┤   (7 sources)      │ Security Analyst│             ▼
endoflife.date ──┤                    │ Evidence Analyst│── gate ─▶ OSSEvent ─▶ are YOU affected?
Docker Hub ──────┘                    │ Report Analyst │   (confidence + impact + evidence)
                                      └───────────────┘

Principles that make it different:

• Evidence-first. Every event carries source URLs, announcement/effective dates, and a confidence level (CONFIRMED / CORROBORATED / EMERGING / UNVERIFIED). No black boxes.
• No mystery scores. Instead of Risk: 72, you see per-facet signals — activity, security, lifecycle, support, license, distribution, popularity.
• Impact attribution. docker.io/bitnami/redis and docker.io/redis resolve to different canonical projects, so a Bitnami distribution event alerts Bitnami users without false-alarming upstream Redis users.
• Honest verdicts. RELATED ≠ AFFECTED, AFFECTS_PROJECT ≠ AFFECTS_VERSION, UNKNOWN ≠ NOT_AFFECTED — same project never means affected, and cleared dependencies say NOT_AFFECTED, not "no match".
• Analysts, not one giant agent. Four small, deterministic, testable analysts. The evidence gate has veto power.

What OpenPulse is not

Existing category	Asks	OpenPulse instead asks
Lifecycle database (endoflife.date)	When does software reach EOL?	What is changing upstream, and does it affect what I depend on?
Vulnerability database (OSV/NVD)	Is this package vulnerable?	Same question, plus: is the match identity-strong or keyword-only?
SCA / scanners	What dependency risks exist in my code?	What changed upstream since we last looked?
Dependency updater	Should I upgrade?	What breaks if I don't — and by when?

endoflife.date is one of our sources, not our definition: lifecycle data enters as raw signals, gets correlated into stories, and is gated like everything else. We do not compete on EOL record counts.

Who it's for — and what you get

• Software security teams / AppSec — extend vulnerability management beyond CVEs: EOL software, exploited-in-the-wild (CISA KEV) correlation, license and support-model drift, with evidence you can paste into a risk register.
• Platform / DevOps engineers — early warning before registry deletions, tag removals, and chart breakages hit pipelines. The Bitnami case is the reference implementation.
• Engineering leaders — useful lead time before an upstream change becomes a production problem, ranked by action-worthiness instead of CVE counts.
• Contributors — a clean, typed Python codebase where every collector and analyst is a pure, tested function. See Contributing.

Status — working today

• 7 collectors: GitHub releases, OSV, NVD, MITRE CVE, CISA KEV, endoflife.date, Docker Hub registries. All degrade gracefully (errors become data, never crashes).
• 4 analysts: Change, Security, Evidence, Report — plus an evidence gate (UNVERIFIED can never emit ACTION).
• Change engine: corruption-detecting digest-aware registry observations (hash-chained local history, frozen sealed records, per-repo locks; the chain is unkeyed, so it does not yet resist an adversary with write access to .openpulse/ - keyed integrity is planned for v0.7.0), observation diffs (openpulse observe), catalog sweep with first-detection tracking (openpulse sweep, report --with-sweep).
• Entity resolution: canonical catalog with PURL builders, Bitnami-namespace rules, and identity trust (VERIFIED / REVIEW_REQUIRED / UNVERIFIED — untrusted mappings cap verdicts at EMERGING).
• CLI: validate events, run analysts live or offline, observe registries, sweep the catalog, render per-project Pulse, generate monthly reports, check watchlists, CycloneDX or SPDX SBOMs, npm/poetry/Cargo lockfiles, requirements/pyproject/pom/go.mod/Cargo manifests (namespaced Maven POMs included), and GitHub repositories (--github-repo, commit- and blob-SHA-pinned, with COMPLETE/PARTIAL/FAILED inspection coverage; manifests, lockfiles, SBOMs and image lists found in the repo are all read) with digest + webhook delivery, show upcoming deadlines (openpulse digest, openpulse warnings), emit evidence-contract v1.1 documents (openpulse attest), and replay the Bitnami case end to end. Webhook delivery enforces an SSRF policy (https by default; --webhook-allow-http opts in) and never prints the webhook URL path; pass the URL as OPENPULSE_WEBHOOK_URL and tokens as GITHUB_TOKEN to keep them out of the process list.
• 740+ offline tests (count reported by CI), ruff clean, CI green (Linux + Windows, incl. CodeQL + pip-audit, lock-drift check, deterministic SBOM, secret tripwire).

What's new in v0.6.1

v0.6.1 is the first release since v0.5.0 and also carries the v0.6.0 work. Full notes: CHANGELOG.md.

• More of your dependencies, checked the same way. check and attest read SPDX SBOMs, npm/poetry/Cargo lockfiles, requirements/pyproject/pom/go.mod/Cargo manifests, container image lists, and whole GitHub repositories (--github-repo). All of them feed the same verdict engine.
• Honest coverage. Repository inspection reports COMPLETE, PARTIAL or FAILED, and an inspection that couldn't read something never claims "no dependencies".
• Early-warning views. openpulse digest and openpulse warnings show upcoming deadlines, with lead times taken from first detection.
• Machine-readable verdicts. openpulse attest emits evidence-contract v1.1 documents.
• Correctness and security fixes. Real-world (namespaced) pom.xml files no longer parse to zero dependencies. Private-registry image refs (host:port/...) keep distinct identities. Webhook errors no longer leak the secret URL path. Locks are OS-level and crash-safe. Every input read is bounded.
• Upgrade note. The local history stays corruption-detecting, not yet tamper-proof. Keyed integrity is planned for v0.7.0 (docs/NEXT_PHASES.md).

Quickstart

pip install -e ".[dev]"

# 1. Validate the Bitnami reference event (CONFIRMED/ACTION, 3 official evidences)
openpulse validate --event data/fixtures/bitnami/event.json --strict

# 2. Replay the north-star scenario offline:
#    Bitnami event -> evidence gate -> which sample dependencies are affected -> report
openpulse demo-bitnami

# 3. Run live analysts against a real project (network; degrades gracefully)
openpulse analyze --project redis
openpulse analyze --project bitnami

# 4. Record a registry observation and diff it against history
openpulse observe --namespace bitnami --repo redis

# 5. Generate the monthly report (offline bundles or live collectors)
openpulse report --month 2026-09 --raw-bundle-dir path/to/bundles

# 6. Check your watchlist against an event (Early Warning preview)
openpulse check --watchlist data/fixtures/watchlist_sample.yaml --event data/fixtures/bitnami/event.json

   # or feed a CycloneDX SBOM (composable with a watchlist)
openpulse check --sbom data/fixtures/sbom/cyclonedx.json --event data/fixtures/bitnami/event.json

   # SPDX 2.x SBOMs work the same way, and compose with both
openpulse check --spdx data/fixtures/sbom/spdx.json --event data/fixtures/bitnami/event.json

   # container image inventories compose too (one ref per line, or a YAML list)
openpulse check --images data/fixtures/images/inventory_sample.txt --event data/fixtures/bitnami/event.json

   # lockfiles too: package-lock.json, poetry.lock or Cargo.lock (pinned entries only,
   # unpinned/workspace entries are skipped with reasons, never range-guessed)
openpulse check --lockfile data/fixtures/lockfiles/poetry.lock --event data/fixtures/django-eol/event.json

    # emit one evidence-contract v1 JSON document per dependency x event pair (JSONL)
openpulse attest --watchlist data/fixtures/watchlist_sample.yaml --event data/fixtures/bitnami/event.json

    # and package manifests: requirements.txt, pyproject.toml, pom.xml, go.mod or Cargo.toml
    # (pinned entries only; ranges/property refs/non-registry sources are skipped with reasons)
openpulse check --manifest data/fixtures/manifests/requirements.txt --event data/fixtures/django-eol/event.json

# 7. Check a whole GitHub repository (public; set GITHUB_TOKEN for private ones)
openpulse check --github-repo owner/repo --event data/fixtures/bitnami/event.json

# 8. Upcoming deadlines for your dependencies (90-day window; `check --ledger` records first detection)
openpulse warnings --watchlist data/fixtures/watchlist_sample.yaml --event data/fixtures/django-eol/event.json
openpulse digest   --watchlist data/fixtures/watchlist_sample.yaml --event data/fixtures/django-eol/event.json

# 9. Post the check digest to Slack-style webhooks (URL via env var, never argv)
OPENPULSE_WEBHOOK_URL=https://hooks.slack.com/services/...   openpulse check --watchlist data/fixtures/watchlist_sample.yaml --event data/fixtures/bitnami/event.json --digest

# 10. Run the test suite
pytest -q

Expected demo-bitnami result: 🚨 on every bitnami* ref, ✅ on upstream redis / postgres / nginx — the distinction traditional tooling doesn't make.

Outputs — what you get

Every month OpenPulse produces two decision-support briefings (see reports/ for real examples). They read like security intelligence, not database exports: ranked findings with evidence confidence, scope, timing, and a recommended investigation — never raw CVE/EOL dumps, never claims about your environment without a watchlist.

![October 2026 monthly intelligence briefing]

Monthly intelligence (openpulse report --month YYYY-MM [--with-sweep]):

• Executive Summary — material changes, attention items, upcoming warnings, non-lifecycle discoveries, evidence confidence, data gaps.
• Top Changes — deterministic evidence-aware ranking (non-lifecycle first, never raw counts). Every card shows announcement, effective, first-detected and last-verified dates, freshness status, evidence confidence, scope, and a recommended investigation.
• Discovery of the Month — the strongest non-lifecycle story, broken out as WHAT / WHY / HOW DETECTED / AFFECTED / NOT AFFECTED / EVIDENCE / ANNOUNCED / DETECTION / WARNING WINDOW.
• Changes Requiring Attention, Upcoming Changes (detection lead times from first trustworthy detection only), Changes by Category, Evidence Quality, What OpenPulse Watches, Methodology.
• What OpenPulse Added This Month — value demonstrated from the report's own data, ending in the public → watchlist → impact → warning progression.
• For Your Environment (public/customer boundary) and an appendix with historical findings, every current finding, sources, and gaps.
• Machine-readable companion: report --metadata-out writes a .meta.json sidecar (report ID, period, version, freshness policy, coverage, status/category counts) for web frontends.

Lifecycle posture (openpulse lifecycle-report --month YYYY-MM):

• Executive Summary, Upcoming Deadlines table (soonest first), Recently Ended, Coverage Gaps (NO-DATA is a limitation, never OK), Top Planning Items, and the full coverage matrix as an appendix.

Repo layout

core/schema/        # v0.5.0 Intelligence Schema — the source of truth
core/entities/      # catalog + resolve() — canonical Project <-> Package/Artifact
core/evidence/      # policy + provenance + independence — the gate with veto power
core/observations/  # RegistryObservation + local history store + diffs
core/risk/          # match.py — event-vs-dependency impact matching
core/pulse.py       # compute_pulse() — findings/events to 7 facets
collectors/         # github, osv, nvd, cve, kev, endoflife, registries (+base)
analyzers/          # change_analyst, security_analyst, evidence_analyst, report_analyst
cli/                # openpulse CLI (validate, pulse, analyze, observe, report, check, demo-bitnami)
reports/            # generate.py — monthly ranked markdown reports
data/               # canonical_projects.yaml, openpulse100 seed, bitnami fixture
docs/               # METHODOLOGY, ROADMAP, ANALYSTS, ARCHITECTURE_REVIEW, ...
tests/              # 740+ offline tests (no network in CI)

The commercial SaaS layer (openpulse-saas/) is intentionally not in this repo — the OSS intelligence core stays independent.

Docs

Doc	Content
docs/METHODOLOGY.md	Sources, evidence rules, confidence levels, limitations
docs/ROADMAP.md	M1–M8 milestones, principles, metrics, Next 90 Days
docs/ANALYSTS.md	The four analysts and their rules
docs/ARCHITECTURE_REVIEW.md	Architecture & security assessment, finding matrix, migration plan
docs/BITNAMI_VALIDATION.md	The Phase-3 acceptance gate
docs/EVIDENCE_CONTRACT.md	Evidence contract v1 / v1.1 — machine-readable dependency verdicts
docs/NEXT_PHASES.md	v0.6.1 → v0.7.0 development plan from the 2026-10-21 security review
CHANGELOG.md	What changed in each release
SECURITY.md	How to report a vulnerability, supported versions, known limitations

Roadmap

M1 Trusted Evidence ✅ done (maintenance) → M2 Upstream Discovery ✅ acceptance met (5 verified cases; 5 live-replayed) → M3 Report Product ✅ briefing + metadata live → M4 Benchmark 🔨 11 of 10–15 formalized → M5 Dependency Context ✅ (watchlist, SBOM, image inventory, lockfile, manifest and GitHub-repo inputs on one verdict engine) → M6 Early Warning 🔨 (ledger, digest, warnings, webhook shipped; delivery state, dedup/retry and CI/PR integration next; SaaS future) → M7 Network → M8 AI-mediated direction → M9 combined assurance experiment (research). Full sequence, layers, principles, metrics: docs/ROADMAP.md; research framing: docs/research/RESEARCH_ALIGNMENT.md; P0–P3 backlog: docs/research/BACKLOG.md.

Deliberately not on the roadmap: becoming an EOL database, another generic SCA, collector-count vanity, AI reasoning in the trusted decision path. They don't prove the core hypothesis.

Contributing

Evidence-first means contributions are easy to review:

1. Add a collector — subclass collectors/base.py:9, add parse_* pure functions, offline fixture tests. Network failures must return error dicts, never raise.
2. Add an analyst rule — extend the relevant analyzers/*_analyst.py, document the rule in docs/ANALYSTS.md, cover it with tests.
3. Add a project — append to data/canonical_projects.yaml (lowercase, tag-free aliases; tests enforce hygiene).
4. Every event needs: source URL + fetch date + confidence. UNVERIFIED can never be ACTION.

ruff check .   # must pass
pytest -q      # must pass (offline)

Good first issues are labeled good first issue.

Security

Found a vulnerability, including an input that makes OpenPulse confidently wrong? Please report it privately through GitHub's Report a vulnerability button (Security tab). Do not open a public issue. Scope, response times and known limitations: SECURITY.md.

Contributors

Thank you to everyone moving OpenPulse forward:

• @wufangyong973 — grew the canonical project catalog toward OpenPulse 100 (Airflow, Spark, MinIO, Celery, ZooKeeper) in #11. First of many.
• @DYNOSuprovo — ASCII-marker fallback for openpulse check on non-UTF-8 consoles in #14 (merged via #17).
• @choksi2212 — six good-first-issue contributions: Unicode fallback for every CLI command (#21), OSV live wiring (#22), catalog identity metadata for forks/renames/ecosystem mappings (#23), intelligence-semantics documentation (#24), SBOM artifact upload (#25), and the Windows CI runner (#26).

License

Apache-2.0 — see LICENSE. Commercial use, modification, and distribution are welcome; the SaaS service layer lives outside this repo.