go-cfenv

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Every change lands on master as its own commit through a pull request, so the
repository carries the development history between releases rather than only
release commits — for example the commits between the last two releases:
https://github.com/cloudfoundry-community/go-cfenv/compare/v1.22.0...v1.23.0
Interim versions are additionally tagged as dev prereleases and are resolvable
by consumers; v1.24.0-dev.1 is the current one. The practice is documented under
"Interim versions" in
https://github.com/cloudfoundry-community/go-cfenv/blob/master/CONTRIBUTING.md

Repository on GitHub, which uses git. git is distributed.

Every release has a unique semantic-version git tag and a corresponding GitHub
release; no tag is ever reused. Releases to date run from v1.19.0 through
v1.23.0, with v1.24.0-dev.1 as the current interim version.
https://github.com/cloudfoundry-community/go-cfenv/releases

Releases use semantic versioning: v1.19.0 through v1.23.0, with prerelease identifiers for interim versions such as v1.24.0-dev.1.

Every release is identified by an annotated git tag, and interim versions by a
dev prerelease tag:
https://github.com/cloudfoundry-community/go-cfenv/tags
The tag body carries the assembled release notes, which the GitHub release then
publishes.

Release notes are published with each GitHub release, following the standard GitHub convention. They are assembled from per-PR changelog.d fragments rather than being a version-control log:
https://github.com/cloudfoundry-community/go-cfenv/releases/tag/v1.23.0

Release notes are assembled from per-PR changelog.d fragments and carry a
dedicated [Security Updates] section. v1.23.0 documents the 16 known
vulnerabilities cleared by moving golang.org/x/net and golang.org/x/text to
current releases:
https://github.com/cloudfoundry-community/go-cfenv/releases/tag/v1.23.0
No vulnerability has ever been reported in this project's own code; the
entries to date concern dependencies.

Bug reports are submitted through the project's GitHub issue tracker, which is
open to anyone with a GitHub account:
https://github.com/cloudfoundry-community/go-cfenv/issues
CONTRIBUTING.md points contributors at the same tracker, and SECURITY.md
directs security-sensitive reports to the Cloud Foundry Foundation security
team instead.

We are using GitHub issues to track bugs and enhancments.

Every open bug report was acknowledged and closed in the last 12 months.
Issues #11, #23, #25 and #28 each received a substantive response and a
released fix in July 2026, and #38 was opened and resolved within a day.
https://github.com/cloudfoundry-community/go-cfenv/issues?q=is%3Aissue+is%3Aclosed

Both outstanding enhancement requests were implemented and released: #23 (nested credential access) in v1.20.0 and #28 (file-based service bindings, RFC-0030) in v1.22.0. Each received an explanatory response describing the design and its limits.

The issues and PRs provide the reports and responses.

https://github.com/cloudfoundry-community/go-cfenv/issues
https://github.com/cloudfoundry-community/go-cfenv/pulls

https://github.com/cloudfoundry-community/go-cfenv/blob/master/SECURITY.md

SECURITY.md documents the process: vulnerabilities are reported privately to
the Cloud Foundry Foundation Security Team at security@cloudfoundry.org, which
acts as the single point of contact and coordinates investigation.

https://github.com/cloudfoundry-community/go-cfenv/blob/master/SECURITY.md

SECURITY.md provides a private reporting address (security@cloudfoundry.org)
and a PGP public key for encrypted mail, fingerprint
3FC8 9AF3 940B E270 CF25 E122 9965 0006 EF9D C642, obtainable from
keys.openpgp.org. GitHub's private vulnerability reporting is also enabled on
the repository, giving a second private channel.

No vulnerability reports have been received for this project in the last 6 months, so there is no response time to report. The repository has no published or draft security advisories.

Non-trivial build file in repository: https://github.com/cloudfoundry-community/go-cfenv/blob/master/Makefile.

The build uses GNU Make and the standard Go toolchain, both conventional for Go
projects. make build, make test and make check wrap ordinary go build,
go test and go vet invocations, so the package can equally be built with the
Go toolchain alone and no project-specific tooling.
https://github.com/cloudfoundry-community/go-cfenv/blob/master/Makefile

The build uses only FLOSS tools: the Go toolchain (BSD-3-Clause), GNU Make (GPL), and golangci-lint (GPL-3.0). No proprietary tool is required to build or test the package.

The package ships a Go test suite under the same Apache-2.0 license, run with
make test or make test-race. Sources: cfenv_test.go, environment_test.go,
envmap_test.go and fuzz_test.go in the repository root.
https://github.com/cloudfoundry-community/go-cfenv/blob/master/cfenv_test.go

go test ./... is the standard invocation for Go and works directly on a clean
checkout. The Makefile wraps it as make test, make test-race and
make cover, and CONTRIBUTING.md documents those as the commands that must pass
before a pull request is merged.

Statement coverage is 93.6%, reported by make cover and measured in CI on
every pull request. The suite covers the VCAP_APPLICATION and VCAP_SERVICES
parsing paths, all service lookup helpers, the credential accessors, and the
file-based binding path including its failure modes.

Every push and every pull request runs the CI workflow: a build at the declared
Go floor, the full test suite under the race detector, coverage, the quality
gates (gofmt, go vet, golangci-lint, actionlint, changelog validation) and a
security audit (govulncheck, gosec, gitleaks, archived-dependency scan). CodeQL
and OpenSSF Scorecard run as separate workflows.
https://github.com/cloudfoundry-community/go-cfenv/blob/master/.github/workflows/ci.yml
Dependabot additionally proposes dependency updates, and those proposals go
through the same CI before merge.

CONTRIBUTING.md states that new functionality must arrive with tests covering
it and that bug fixes must arrive with a regression test, and that make check
and make test-race must pass before merge. CI enforces both on every pull
request.
https://github.com/cloudfoundry-community/go-cfenv/blob/master/CONTRIBUTING.md

Every recent feature shipped with tests. v1.20.0 added the Credential and CredentialPath accessors with 16 new cases plus a regression test pinning the payload from issue #11; v1.21.0 added the binding-metadata fields with cases for a fully populated and an omitted binding; v1.22.0 added file-based service bindings with five cases including unreadable and malformed files. Coverage rose from 89.4% to 93.6% across those three releases.

The policy is written into CONTRIBUTING.md under "Testing policy": new
functionality must arrive with tests covering it, and a bug fix must arrive with
a test that fails without the fix.
https://github.com/cloudfoundry-community/go-cfenv/blob/master/CONTRIBUTING.md

go vetand golangci-lint both run as part ofmake check` and in the CI
quality-gates job on every pull request. The golangci-lint configuration enables
a large explicit linter set rather than the defaults:
https://github.com/cloudfoundry-community/go-cfenv/blob/master/.golangci.yml
GitHub Actions workflow files are additionally linted with actionlint.

Warnings are build failures rather than advisories: make check exits non-zero
on any finding from gofmt, go vet, golangci-lint or actionlint, and the CI
quality-gates job fails the pull request. The tree currently reports zero
issues.

golangci-lint runs with a large explicit linter set rather than the defaults,
alongside go vet, and every finding fails the build — make check exits
non-zero and the CI quality-gates job fails the pull request. The tree currently
reports zero issues. The go directive was raised to 1.25 in v1.23.0 in part to
lift linters that the older floor had disabled at runtime (copyloopvar,
intrange); both now run.
https://github.com/cloudfoundry-community/go-cfenv/blob/master/.golangci.yml

The primary maintainer has professional experience in secure design across
Cloud Foundry platform work, applying least privilege, input validation at trust
boundaries, and secure defaults. In this project that shows up as treating
platform-supplied VCAP_APPLICATION and VCAP_SERVICES documents as untrusted
input: they are fuzz-tested, and parsing failures are surfaced as errors rather
than silently producing an empty configuration.

I have been dealing with secure environments since the beginning of my career,
IEN-73 refers to Internet Experiment Note 73, titled "A TCP Implementation Issue", published on January 23, 1979, by N. Abramovitz, M. Padlipsky, and K. Biba. It is a historical document from the early development phase of the TCP/IP internet architecture addressing technical implementation challenges.

I also worked on the KSOS (Ksernelized Secure Operating System) project in the networking area.

I am currently adding nonces to the Stratos project to close code-injection vectors: https://github.com/cloudfoundry/stratos

The maintainer is familiar with the common error classes for a parsing library
of this kind and their mitigations: unvalidated input from an untrusted source
(countered by fuzzing the parser and returning errors rather than partial
results), injection through data interpreted as configuration, unsafe handling
of file paths supplied by the environment, and dependency-supply-chain exposure
(countered by govulncheck, gosec, gitleaks, an archived-dependency gate, and
Dependabot in CI)

This package produces no cryptographic functionality. It parses the
VCAP_APPLICATION and VCAP_SERVICES documents Cloud Foundry places in the
application environment and exposes them as Go types. It implements no
cryptographic algorithm, calls no cryptographic library, and opens no network
connection, so this criterion does not apply.

This package produces no cryptographic functionality. It parses the
VCAP_APPLICATION and VCAP_SERVICES documents Cloud Foundry places in the
application environment and exposes them as Go types. It implements no
cryptographic algorithm, calls no cryptographic library, and opens no network
connection, so this criterion does not apply.

This package produces no cryptographic functionality. It parses the
VCAP_APPLICATION and VCAP_SERVICES documents Cloud Foundry places in the
application environment and exposes them as Go types. It implements no
cryptographic algorithm, calls no cryptographic library, and opens no network
connection, so this criterion does not apply.

This package produces no cryptographic functionality. It parses the
VCAP_APPLICATION and VCAP_SERVICES documents Cloud Foundry places in the
application environment and exposes them as Go types. It implements no
cryptographic algorithm, calls no cryptographic library, and opens no network
connection, so this criterion does not apply.

This package produces no cryptographic functionality. It parses the
VCAP_APPLICATION and VCAP_SERVICES documents Cloud Foundry places in the
application environment and exposes them as Go types. It implements no
cryptographic algorithm, calls no cryptographic library, and opens no network
connection, so this criterion does not apply.

This package produces no cryptographic functionality. It parses the
VCAP_APPLICATION and VCAP_SERVICES documents Cloud Foundry places in the
application environment and exposes them as Go types. It implements no
cryptographic algorithm, calls no cryptographic library, and opens no network
connection, so this criterion does not apply.

This package produces no cryptographic functionality. It parses the VCAP_APPLICATION and VCAP_SERVICES documents Cloud Foundry places in the application environment and exposes them as Go types. It implements no cryptographic algorithm, calls no cryptographic library, and opens no network connection, so this criterion does not apply.

This package does not store or authenticate passwords. It surfaces credentials that the platform has already placed in the application environment, and never persists them.

This package generates no random values for any security purpose. It performs parsing only.

Distribution channels use HTTPS exclusively: the repository, the Go module proxy and the checksum database are all reached over TLS.

The package is delivered through the Go module system. Module content is verified against cryptographic hashes recorded in go.sum and cross-checked against the public transparency log at sum.golang.org; the proxy and the checksum database are reached over HTTPS, as is the repository. No hash is retrieved over plain http.

There are no unpatched vulnerabilities. None has ever been reported in this project's own code. The dependency exposure that existed - 16 known vulnerabilities carried by the pinned versions of golang.org/x/net and golang.org/x/text - was cleared in v1.23.0, and OSV now reports none for any module in the dependency graph. govulncheck runs in CI on every pull request.

No critical vulnerability has been reported in this project. The dependency vulnerabilities identified during a security review were cleared in the next release, which raised the Go floor specifically to make those upgrades possible.

The repository contains no credentials. gitleaks runs in the CI security-audit
job on every pull request and scans the full history — the job checks out with
fetch-depth 0 precisely so history is scanned rather than a single commit — and
reports no findings. The only credential-shaped strings in the tree are the
fictional sample values inside test fixtures for VCAP_SERVICES.

Several run on every pull request and therefore on every release commit:
golangci-lint with an explicit linter set, gosec, CodeQL, and govulncheck.
make check and make audit run the same tools locally.
https://github.com/cloudfoundry-community/go-cfenv/blob/master/.github/workflows/ci.yml

gosec and CodeQL are both specifically vulnerability-oriented. gosec applies Go security rules such as unsafe file paths, weak randomness and command injection; CodeQL runs GitHub's Go security query suite. govulncheck additionally matches the dependency graph against the Go vulnerability database using reachability analysis.

Static analysis findings block merge rather than being triaged later: the quality-gates and security-audit CI jobs fail the pull request on any finding. All findings raised to date have been fixed before merge, and the tree currently reports none.

Static analysis runs on every push and every pull request through the CI workflows, not on a schedule. CodeQL and the OpenSSF Scorecard workflow run additionally on their own cadence.

Two forms run: the Go race detector over the full test suite (make test-race, in CI on every pull request) and coverage-guided fuzzing of the VCAP_APPLICATION and VCAP_SERVICES parsers (make fuzz, target FuzzNew in fuzz_test.go). The fuzz seed corpus also runs as part of the ordinary test suite.

The project produces no software written in a memory-unsafe language. It is pure Go, which is memory-safe, and uses no cgo and no unsafe package.

The test and fuzz runs execute under the Go race detector (make test-race), which instruments every memory access and reports data races at run time. It is enabled for testing only and never in consumer builds, which is the separation this criterion asks for.

Dynamic analysis is run in two forms: the Go race detector on the full test
suite (make test-race, run in CI on every pull request) and coverage-guided
fuzzing of the VCAP_APPLICATION and VCAP_SERVICES parsers (make fuzz). The
seed corpus runs as part of the ordinary test suite. No defect has been found by
either — the fuzz target has been run to roughly 10 million executions without a
finding — so none is outstanding.