A read-only health and security scanner for Cloud Foundry landscapes on SAP BTP.

BAIP Lens scans a Cloud Foundry (CF) org on SAP BTP (Business Technology Platform). Today it inventories the apps your user can see, flags stale deployments and writes an offline HTML report plus data files. The other v0.1 checks are planned.

Open source under Apache-2.0, free for everyone, built in public, and it runs on your machine.

Run it from source · v0.1 in development

0.1.0 is not published yet; npx baip-lens currently downloads an empty 0.0.1 placeholder and stops with an npm error.

You need git, Node.js 22.12 or later, and a BTP login with the read-only Space Auditor role in each space you want scanned. You do not need the cf command-line tool (CLI).

git clone https://github.com/sebastianomarchesini/baip-lens.gitcd baip-lensgit checkout 9fe7d0db6498npm ci && npm run buildnode packages/cli/dist/cli.js

Pinned to commit 9fe7d0db6498, the one the tool pages on this site are synced from.

If something does not work, run node packages/cli/dist/cli.js doctor --api <your CF API URL> in the same folder. It checks Node.js, the connection and certificates to your CF API (application programming interface), any cf CLI login and the output folder.

After 0.1.0 is published: npx baip-lens

See the sample report Start here

Read-only, by construction

Is it safe to run with my production login?

Read-only

It sends only GET requests to the Cloud Foundry API.

The HTTP client refuses any method other than GET to the CF API. The only POST requests go to the OAuth token endpoint (the sign-in standard Cloud Foundry uses) and to the OSV.dev vulnerability batch API.

CF API: GET only · POST: /oauth/token, OSV.dev querybatch

Egress allow-list

Requests go only to your CF landscape and four public lookups.

Every request BAIP Lens makes, including the token request to your UAA (User Account and Authentication) server, goes through a built-in allow-list, and redirects are never followed. There is no telemetry. What is sent to each host

your CF API
your UAA or login server
your log cache (from v0.2)
api.osv.dev
endoflife.date
ui5.sap.com
registry.npmjs.org
your app routes (planned)

telemetry: none · report folders 0700, files 0600 (macOS, Linux)

Least privilege

Space Auditor, a read-only role, is enough for the default scan.

User names, tokens and secret values are never written into its output. When a call returns 403, the check is recorded as skipped: insufficient role and the scan continues. Spaces your user cannot see are filtered out by the Cloud Foundry API rather than refused with a 403, so they are not reported as skipped.

The opt-in --deep flag is reserved for a planned secrets check. That check will need Space Developer or Space Supporter, neither of which is read-only, and Cloud Foundry will record an audit event for each app whose variables it reads. Permissions for --deep

minimum role: Space Auditor · 403: skipped, scan continues

One file, opens offline

See the sample report

Overview page of the sample report for the acme-prod landscape: a plain-words summary, tiles for 8 apps scanned and 0 critical or high findings, a findings-by-severity chart (1 medium, 2 low) and the three top risky apps — fig. 1 · Sample report from the synthetic acme-prod fixture landscape: 8 apps, 3 findings (1 medium, 2 low).

Formats: A single-file HTML report plus JSON (JavaScript Object Notation), CSV (comma-separated values) and SARIF 2.1.0 (Static Analysis Results Interchange Format). The CSV output neutralizes spreadsheet formulas; the SARIF output is ready for code-scanning tools.
Offline: Fonts, themes and data are embedded. The report follows your light or dark system setting and works at phone width.
Locked down: It carries a Content Security Policy with connect-src 'none', so the browser itself refuses to let it connect anywhere, and only the scripts bundled at build time may run.
Re-run offline: node packages/cli/dist/cli.js report --from <snapshot.json> re-runs every rule on a snapshot, for example after you upgrade BAIP Lens.
Exit codes: 0: no findings at or above --fail-on (the default, none, never fails). 1: findings met the threshold. 2: tool error.

What it checks in v0.1

All rules, with evidence and remediation

Every finding has a stable rule id, a severity, the evidence that triggered it, a concrete remediation and reference links. Rules are pure functions of the collected data. They use the scan time as "now", so node packages/cli/dist/cli.js report --from <snapshot.json> gives the same result offline.

Rules in v0.1: status, severity and the minimum Cloud Foundry role each needs
Rule id	What it flags	Status	Severity	Needs
APP_NO_RECENT_DEPLOY	Last deploy older than 12 months	implemented	low / medium	Space Auditor
RUNTIME_NODE_EOL, RUNTIME_JAVA_EOL	The runtime version is past, or within 90 days of, its end of life (EOL)	planned, slice 2	medium / high	Space Auditor
DEP_KNOWN_CVE	A dependency in the SBOM (software bill of materials) has a known vulnerability (a CVE, a Common Vulnerabilities and Exposures entry)	planned, slice 3	from CVSS (Common Vulnerability Scoring System)	none (local SBOM)
APP_IDLE	The app is stopped for a long time, or runs with no sign of use	planned, slice 4	low	Space Auditor
UI5_OUT_OF_MAINTENANCE	The SAPUI5 version served by the app is out of maintenance	planned, slice 5	medium / high	Space Auditor
BUILDPACK_OUTDATED	The droplet was built with an older buildpack than the platform currently offers	planned	low / medium	Space Auditor
STACK_DEPRECATED	The app runs on a deprecated stack	planned	medium / high	Space Auditor
SAP_PKG_OUTDATED	@sap/cds, @sap/approuter, @sap/xssec or @sap/xsenv is behind the current major version	planned	medium / high	none (local SBOM)
ENV_SECRET_PLAINTEXT	An environment variable whose name looks like a secret is set directly on the app	planned	high	Space Developer or Space Supporter, `--deep`

Two severities mean the rule picks one by threshold: APP_NO_RECENT_DEPLOY is low when the current droplet is more than 365 days old and medium past 730 days; the runtime rules are medium within 90 days of end of life and high past it. For planned rules the severity logic is the design, confirmed or adjusted when the rule is implemented.

Apps are ranked by a weighted sum of their findings: critical 100, high 25, medium 5, low 1, info 0. A score of 0 means that no rule matched; it does not mean the app is safe.

Posts and guides

All posts

The first posts are in review and will appear here when they are published.

Start here

New to Cloud Foundry on SAP BTP: these pages in reading order, then the posts as they are published.

The sample report, built from a synthetic fixture
Permissions: which role a scan needs
Privacy: where requests go and what is never kept
Getting started without being a developer (works once 0.1.0 is published)

The full path