Close the remaining OpenSSF Scorecard gaps, including the Best Practices badge

[norman-abramovitz]

The Scorecard sits at 6.6. Several remaining gaps need work outside this
repository — registering with an external service, or changing how changes are
merged — so they are grouped here rather than left implicit.

Current zero/negative checks, with the reason Scorecard reports:

Check	Score	Reported reason
CII-Best-Practices	0	"no effort to earn an OpenSSF best practices badge detected"
Code-Review	0	"Found 0/6 approved changesets"
Pinned-Dependencies	0	"dependency not pinned by hash detected"
Vulnerabilities	0	"13 existing vulnerabilities detected"
Fuzzing	0	no fuzz targets
Branch-Protection	-1	not determinable with the current token
Signed-Releases	-1	n/a for a library with no artifacts
Packaging	-1	n/a — this is a library, nothing is published to a registry

Needs external registration

• OpenSSF Best Practices badge — register the project at
  https://www.bestpractices.dev/, work through the questionnaire, and add
  the resulting badge (the URL embeds the numeric project ID that
  registration assigns). This is the only item here that cannot be started
  from the repository; it needs a maintainer with an account to claim the
  project. Registering is also what moves CII-Best-Practices off 0.

Repository-side

• Code-Review 0/6 — a direct consequence of self-merged PRs. Needs
  either a second reviewer on the org side, or an explicit decision to
  accept the score for a single-maintainer library. Worth deciding rather
  than leaving to drift.
• Branch-Protection -1 — Scorecard cannot read the setting with the
  default token. Confirm protection is actually enabled on master; the
  -1 means "unknown", not "absent".
• Fuzzing 0 — New parses attacker-influenced JSON from
  VCAP_SERVICES, which is a genuinely reasonable fuzz target. Small, and
  the most defensible of the remaining items.

Decide and document, probably won't-fix

• Pinned-Dependencies 0 — GitHub Actions are referenced by tag rather
  than SHA. This was a deliberate choice (the same finding is accepted from
  zizmor's unpinned-uses). Either pin to SHAs and accept the Dependabot
  churn, or record the decision somewhere durable so it stops reading as an
  oversight.
• Signed-Releases / Packaging -1 — not applicable to a library that
  ships no binaries. No action; noted so they are not re-investigated.

Tracked elsewhere

Vulnerabilities is blocked on the go directive floor — see #38. It is listed
above only to explain the current score.

[norman-abramovitz]

Steps that have to be done out of band

These need a maintainer account or org-level settings; nothing in the repository can do them. Recording them here so they are actionable without re-deriving anything.

1. OpenSSF Best Practices badge — moves CII-Best-Practices 0 → non-zero

1. Sign in at https://www.bestpractices.dev/ with the GitHub account that maintains this repo (OAuth, no separate password).
2. Choose Add project and enter the repo URL https://github.com/cloudfoundry-community/go-cfenv. The site pre-fills what it can infer.
3. Work through the Passing questionnaire. Most of it is already true and just needs asserting — the ones already satisfied here: an OSI license (LICENSE), a documented contribution process (CONTRIBUTING.md), a security reporting channel (SECURITY.md), public version-controlled history, a documented build and test process (make check, make test), a released versioning scheme (semver tags), release notes (the changelog.d mechanism), and static analysis plus a dependency-update tool in CI.
4. On save the project is assigned a numeric ID. The badge URL embeds it:
   • Badge image: https://www.bestpractices.dev/projects/<ID>/badge
   • Badge link: https://www.bestpractices.dev/projects/<ID>
5. Send me the ID, or add the badge to README.md alongside the existing five.

Scorecard reads the badge from the README, so the check stays 0 until both the registration and the README line exist.

2. Branch protection — resolves Branch-Protection -1

-1 means "could not determine", not "absent". Scorecard's default token cannot read branch protection on a public repo without admin scope.

• Confirm at Settings → Branches → Branch protection rules that master has a rule.
• If the intent is for the score to reflect reality, the Scorecard workflow needs a PAT with repo scope stored as a repository secret and referenced by scorecard.yml. That is a real trade-off: it puts a broader-scoped token in CI to improve a score. Declining is reasonable — but decide it rather than leaving it unknown.

3. Code-Review 0/6 — needs a second person, or an explicit decision

Scorecard found 0 of the last 6 changesets approved. Every recent PR here was self-merged, which is what a single-maintainer repo looks like. Two honest options:

• Get a second reviewer from the cloudfoundry-community org onto PRs, and require an approving review in branch protection; or
• Accept that this check cannot pass for a single-maintainer library, and note it so it is not repeatedly re-investigated.

There is no repository-side change that fixes this without one of those.

4. Scanners already covered — no action

For the record, so these are not chased again: SAST 10, Dependency-Update-Tool 10, Security-Policy 10, Token-Permissions 10, Dangerous-Workflow 10, Binary-Artifacts 10, CI-Tests 10, License 10, Maintained 10. Signed-Releases and Packaging are -1 because this library publishes no artifacts to any registry — not applicable.

[norman-abramovitz]

Repository-side work: partly done

Fuzzing 0 → addressed in the branch for #38 (raise-go-floor): FuzzNew fuzzes the VCAP_APPLICATION and VCAP_SERVICES parsing that New performs. Both documents come from the platform and from bound brokers rather than from the app, so they are this package's untrusted boundary.

The asserted property is that New returns an app or an error for any input and never panics, and that the accessors stay total on anything that decoded. Seeded with the shapes already known to be awkward — nested credentials, volume mounts, a null limits, empty strings. 9.7 million executions found nothing. make test runs the seed corpus, since Go fuzz targets are also ordinary tests; make fuzz searches.

Vulnerabilities 0 → addressed by #38, which is where that check was actually blocked.

Pinned-Dependencies 0 — still needs your decision. Actions are referenced by tag, not SHA. This was deliberate; the equivalent finding from zizmor (unpinned-uses) was accepted on the same grounds. The options are to pin to SHAs and absorb the Dependabot churn, or to record the decision durably so it stops reading as an oversight. I have not changed it either way.

[nabramovitz]

Correction to step 1 above: sign up with email, not with GitHub

The earlier comment says to sign in at bestpractices.dev "with the GitHub account that maintains this repo". Disregard that part. The rest of step 1 stands; only the account-creation method changes.

Use https://www.bestpractices.dev/en/signup and create an account with an email address instead. The site supports both methods — "If you don't want to log in with a GitHub account, you can sign up here instead" — and activates the account via an emailed link. Your name is shown publicly; the address stays private.

Why

The GitHub OAuth app requests user:email, read:org, from config/initializers/omniauth.rb in ossf/best-practices-badge:

provider :github, ENV.fetch('GITHUB_KEY', nil), ENV.fetch('GITHUB_SECRET', nil),
         scope: 'user:email, read:org'

Both are read-only. The app cannot read source or write anything, and read:org is there so the site can auto-verify that the authorizing user controls the project.

Two reasons to decline it regardless:

1. read:org spans every organization the authorizing account belongs to, not just this one. That is a much wider grant than registering a single library justifies, particularly for an account that also carries client-org membership.
2. The OAuth app is registered to a personal account, not to the OpenSSF organization. This is legitimate — the program began as the CII Best Practices Badge, built by the same person, before OpenSSF existed, and the app repo is now ossf/best-practices-badge under the OpenSSF org — but the authorization boundary is still an individual account rather than the org the branding suggests. Worth knowing before clicking, and a reasonable thing to have stopped on.

Email signup avoids both. The only thing given up is automatic control-verification, which is not needed when registering the project yourself.

If GitHub OAuth is ever preferred anyway, do it from an account with no client-org membership.