@openzeppelin/hardhat-upgrades
Supply chain provenance
Status for the latest visible version.
Maintainers
Accepted risks
Findings the reviewer chose to accept rather than block on.
| Source | Rule | Reason | Accepted by | When |
|---|---|---|---|---|
| publish-pattern | new-deps-added | AI (publish-pattern): Official first-party @openzeppelin SDK package, expected dependency expansion. | ai | |
| provenance | missing-githead | AI (provenance): Benign publish-metadata gap from trusted long-tenured maintainer. | ai | |
| provenance | publisher-changed | AI (provenance): OpenZeppelin migrated to GitHub Actions CI publishing with SLSA provenance; this is a legitimate org-level change. | ai | |
| semgrep | semgrep:api-obfuscation-reflect | AI (semgrep): Reflect.get() used in a Proxy trap for method binding, not obfuscation; stable pattern in this codebase. | ai | |
| phantom-deps | phantom-dep:undici | AI (phantom-deps): undici is a declared runtime dependency in package.json; phantom-dep false positive. | ai | |
| semgrep | semgrep:dynamic-require | AI (semgrep): The dynamic require is used in a tryRequire helper to probe for optional peer dependencies — a standard, benign plugin pattern with no arbitrary code execution risk. | ai | |
| dependencies | unvetted-dep:@openzeppelin/defender-sdk-network-client | AI (dependencies): First-party OpenZeppelin Defender SDK package; expected dependency for Defender network features. | ai | |
| dependencies | unvetted-dep:ethereumjs-util | AI (dependencies): ethereumjs-util is a well-known Ethereum ecosystem utility library; expected dependency for this plugin. | ai | |
| dependencies | unvetted-dep:@openzeppelin/upgrades-core | AI (dependencies): First-party OpenZeppelin package; core dependency of this official OpenZeppelin plugin. | ai | |
| dependencies | unvetted-dep:@openzeppelin/defender-sdk-base-client | AI (dependencies): First-party OpenZeppelin Defender SDK package; expected dependency for Defender integration features. | ai | |
| dependencies | unvetted-dep:@openzeppelin/defender-sdk-deploy-client | AI (dependencies): First-party OpenZeppelin Defender SDK package; expected dependency for Defender deployment features. | ai |
Versions (showing 22 of 22)
| Version | Deps | Published |
|---|---|---|
| 4.1.0 | 9 / 17 | |
| 4.0.2 | 9 / 15 | |
| 4.0.1 | 9 / 15 | |
| 4.0.0 | 9 / 15 | |
| 3.9.1 | 9 / 12 | |
| 3.9.0 | 9 / 12 | |
| 3.8.0 | 9 / 12 | |
| 3.7.0 | 9 / 12 | |
| 3.6.0 | 9 / 12 | |
| 3.5.0 | 9 / 12 | |
| 3.4.0 | 9 / 12 | |
| 3.3.0 | 9 / 12 | |
| 3.2.1 | 9 / 12 | |
| 3.2.0 | 9 / 12 | |
| 3.1.1 | 11 / 12 | |
| 3.1.0 | 11 / 12 | |
| 3.0.5 | 11 / 12 | |
| 3.0.4 | 10 / 12 | |
| 3.0.3 | 10 / 12 | |
| 3.0.2 | 10 / 12 | |
| 3.0.1 | 10 / 12 | |
| 3.0.0 | 10 / 12 |
v4.1.0
1 findingPublished via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.
v3.9.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.8.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.7.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.6.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.5.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.4.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.3.0
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.2.1
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.
v3.2.0
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.
v3.1.1
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.
v3.1.0
2 findingsThis version has no gitHead field linking it to a source commit, but previous versions did. This suggests the publish environment changed. Published by: ericglau.
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.0.5
2 findingsThis version has no gitHead field linking it to a source commit, but previous versions did. This suggests the publish environment changed. Published by: ericglau.
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.0.4
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.0.3
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.0.2
1 findingPackage was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v3.0.1
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.
v3.0.0
1 findingPackage was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.