From 93ef076d9b9f65294ac97cd0f2d5d27b734b9750 Mon Sep 17 00:00:00 2001 From: manhtukhang Date: Fri, 13 Dec 2024 15:32:07 +0700 Subject: [PATCH 1/2] docs: added Security policy Signed-off-by: manhtukhang --- SECURITY.md | 174 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..cbb059b --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,174 @@ +# Security Policy + +This document includes information about the vulnerability reporting, patch, +release, and disclosure processes, as well as general security posture. + + + + + +- [Supported Versions](#supported-versions) +- [Reporting a Vulnerability](#reporting-a-vulnerability) + - [When Should I Report a Vulnerability?](#when-should-i-report-a-vulnerability) + - [When Should I NOT Report a Vulnerability?](#when-should-i-not-report-a-vulnerability) + - [Vulnerability Response](#vulnerability-response) +- [Security Release & Disclosure Process](#security-release--disclosure-process) + - [Private Disclosure](#private-disclosure) + - [Public Disclosure](#public-disclosure) + - [Security Releases](#security-releases) + - [Severity](#severity) +- [Security Posture](#security-posture) +- [Security Team](#security-team) +- [Security Policy Updates](#security-policy-updates) + + + +## Supported Versions + +The following versions are currently supported and receive security updates. +Release candidates will not receive security updates. + +| Version | Supported | +| --------- | ------------------ | +| >= 0.0.1 | :white_check_mark: | + +## Reporting a Vulnerability + +We're extremely grateful for security researchers and users that report +vulnerabilities to us. All reports are thoroughly investigated by the project +[security team](#security-team). + +Vulnerabilities are reported privately via GitHub's +[Security Advisories](https://docs.github.com/en/code-security/security-advisories) +feature. Please use the following link to submit your vulnerability: +[Report a vulnerability](https://github.com/manhtukhang/vault-plugin-secrets-nexus-repository/security/advisories/new) + +Please see +[Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability#privately-reporting-a-security-vulnerability) +for more information on how to submit a vulnerability using GitHub's interface. + +### When Should I Report a Vulnerability? + +- You think you discovered a potential security vulnerability in vault-plugin-secrets-nexus-repository +- You are unsure how a vulnerability affects vault-plugin-secrets-nexus-repository +- You think you discovered a vulnerability in another project that vault-plugin-secrets-nexus-repository depends on + - For projects with their own vulnerability reporting and disclosure process, please report it directly there + +### When Should I NOT Report a Vulnerability? + +- You need help tuning GitHub Actions for security +- You need help applying security related updates +- Your issue is not security related + +### Vulnerability Response + +Each report is acknowledged and analyzed by the [Security Team](#security-team) +within 14 days. This will set off the +[Security Release Process](#security-release--disclosure-process). + +Any vulnerability information shared with the Security Team stays within +vault-plugin-secrets-nexus-repository project and will not be disseminated to other projects +unless it is necessary to get the issue fixed. + +As the security issue moves from triage, to identified fix, to release planning +we will keep the reporter updated. + +## Security Release & Disclosure Process + +Security vulnerabilities should be handled quickly and sometimes privately. The +primary goal of this process is to reduce the total time users are vulnerable +to publicly known exploits. + +### Private Disclosure + +We ask that all suspected vulnerabilities be privately and responsibly +disclosed via the [private disclosure process](#reporting-a-vulnerability) +outlined above. + +Fixes may be developed and tested by the [Security Team](#security-team) in a +[temporary private fork](https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability) +that are private from the general public if deemed necessary. + +### Public Disclosure + +Vulnerabilities are disclosed publicly as GitHub [Security +Advisories](https://github.com/manhtukhang/vault-plugin-secrets-nexus-repository/security/advisories). + +A public disclosure date is negotiated by the [Security Team](#security-team) +and the bug submitter. We prefer to fully disclose the bug as soon as possible +once a user mitigation is available. It is reasonable to delay disclosure when +the bug or the fix is not yet fully understood, the solution is not +well-tested, or for vendor coordination. The timeframe for disclosure is from +immediate (especially if it's already publicly known) to several weeks. For a +vulnerability with a straightforward mitigation, we expect report date to +disclosure date to be on the order of 14 days. + +If you know of a publicly disclosed security vulnerability please IMMEDIATELY +[report the vulnerability](#reporting-a-vulnerability) to inform the +[Security Team](#security-team) about the vulnerability so they may start the +patch, release, and communication process. + +If possible the Security Team will ask the person making the public report if +the issue can be handled via a private disclosure process. If the reporter +denies the request, the Security Team will move swiftly with the fix and +release process. In extreme cases you can ask GitHub to delete the issue but +this generally isn't necessary and is unlikely to make a public disclosure less +damaging. + +### Security Releases + +Once a fix is available it will be released and announced via the project on +GitHub. +Security releases will announced and clearly marked as a security release and +include information on which vulnerabilities were fixed. As much as possible +this announcement should be actionable, and include any mitigating steps users +can take prior to upgrading to a fixed version. + +Fixes will be applied in patch releases to all [supported versions](#supported-versions) +and all fixed vulnerabilities will be noted in +the [CHANGELOG](./CHANGELOG.md). + +### Severity + +The [Security Team](#security-team) evaluates vulnerability severity on a +case-by-case basis, guided by [CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document). + +## Security Posture + +We aim to reduce the number of security issues through several general +security-concious development practices including the use of unit-tests, +end-to-end (e2e) tests, static and dynamic analysis tools, and use of +memory-safe languages. + +We aim to fix issues discovered by analysis tools as quickly as possible. We +prefer to add these tools to "pre-submit" checks on PRs so that issues are +never added to the code in the first place. + +In general, we observe the following security-conscious practices during +development (This is not an exhaustive list). + +- All PRs are reviewed by at least one [CODEOWNER](./CODEOWNERS). +- All tests must pass before a PRs is merged. +- We refrain from using memory-unsafe languages (e.g. C, C++) or memory-unsafe + use of languages that are memory-safe by default (e.g. the Go + [unsafe](https://pkg.go.dev/unsafe) package). + +## Security Team + +The Security Team is responsible for the overall security of the +project and for reviewing reported vulnerabilities. Each member is familiar +with designing secure software, security issues related to CI/CD, GitHub +Actions and build provenance. + + + +Security Team: + +- Tu KhangManh (@manhtukhang) + +Security Team membership is currently considered on a case-by-case basis. + +## Security Policy Updates + +Changes to this Security Policy are reviewed and approved by the +[Security Team](#security-team). From 98860ea4da1243825e869860286d424a50023b37 Mon Sep 17 00:00:00 2001 From: manhtukhang Date: Fri, 13 Dec 2024 15:34:22 +0700 Subject: [PATCH 2/2] docs: updated Readme Signed-off-by: manhtukhang --- README.md | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 69 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index af42d88..773b1fd 100644 --- a/README.md +++ b/README.md @@ -15,12 +15,16 @@ This is a [(HashiCorp) Vault secrets plugin](https://developer.hashicorp.com/vau Using this plugin, you can limit the accidental exposure window of Nexus Repository user's credentials; useful for continuous integration servers. -> [!IMPORTANT] -> This plugin is in development process, use at your own risk. --- ## INSTALLATION +> [!IMPORTANT] +> This plugin is designed to be `run on Vault servers` and `could connect to Nexus Repository server(s) with high privileges`. +> Therefore, DO NOT use this (or any 3rd party plugins) on critical production environment without understanding about the security risks! +> Please read [SECURITY section](#security) carefully before any uses. + + ### Using pre-built releases You can find pre-built releases of the plugin [here](https://github.com/manhtukhang/vault-plugin-secrets-nexus-repository/releases) and download the latest binary file corresponding to your target OS. @@ -49,7 +53,7 @@ $ vault plugin register \ ``` > [!CAUTION] -> This inline checksum calculation above is provided for illustration purpose and does not validate your binary. It should **not** be used for production environment. Instead you should use the checksum provided as [part of the releases](https://github.com/manhtukhang/vault-plugin-secrets-nexus-repository/releases). +> This inline checksum calculation above is provided for illustration purpose and does not validate your binary. It should **not** be used for production environment. Instead you should use the checksum provided in the release archive file as [part of the releases](https://github.com/manhtukhang/vault-plugin-secrets-nexus-repository/releases). See [Verify downloaded artifact from GitHub releases](#verify-downloaded-artifact-from-github-releases) section. You can now enable the Nexus Repository secrets plugin: ```sh @@ -70,7 +74,7 @@ When upgrading, please refer to the [Vault documentation](https://developer.hash ### Nexus Repository -Create an "admin" user with a role with minimum privileges (refer to [Nexus Repository roles docs](https://help.sonatype.com/en/roles.html)): +Create an "admin" user with a role with minimum privileges (refer to [Nexus Repository roles docs](https://help.sonatype.com/en/roles.html)): ``` nx-users-create nx-user-delete @@ -190,7 +194,7 @@ No renewals or new tokens will be issued if the backend configuration (config/ad * `url` (string) - Address of the Nexus Repository server instance, e.g. https://nexus.myorg.domain * `username` (string) - The "admin" username to access Nexus Repository API. -* `password` (string) - The "admin" password. +* `password` (string) - The "admin" password. * `insecure` (boolean) - Optional. Bypass certification verification for TLS connection with Nexus Repository API. Default to `false`. * `timeout` (time duration) - Optional. Timeout for connection with Nexus Repository API. Default to `30s` (30 seconds). @@ -279,7 +283,7 @@ Get credential (dynamically generate Nexus Repository users) from a specified (V #### Examples ```sh -vault read nexus/creds/test +$ vault read nexus/creds/test ``` ```console Key Value @@ -293,6 +297,65 @@ password um4q4sqx5lJPpsSo8tklSKj6Ic... (password truncated) user_id v-test-token-1733126698 ``` +--- +## SECURITY + +Because of running on and managaging critical systems (Vault, Nexus), we all understand that this plugin can be a vulnerable part due to supply chain integrity weaknesses. +Therefore, to prove that the released binary has not been tampered with and can be securely traced back to source, the plugin is built and attested to the provenance of its release artifacts in the SLSA standard and provisionally meet Level 3 using [`SLSA` framework](https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html)'s generator and Level 2 using [`GitHub's artifact attestation`](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds#about-artifact-attestations). + + +### Verify downloaded artifact from GitHub releases + +Use either or both methods below + +#### Using SLSA verifier + +> [!NOTE] +> `slsa-verifier` is a tool for verifying SLSA provenance that was generated by CI/CD builders. slsa-verifier verifies the provenance by verifying the cryptographic signatures on provenance to make sure it was created by the expected builder. It then verifies that various values such as the builder id, source code repository, ref (branch or tag) matches the expected values. + +Follow this [installation instruction](https://github.com/slsa-framework/slsa-verifier#download-the-binary) to install. + +Verify (e.g for the `vault-plugin-secrets-nexus-repository_v1.0.0-tb1_linux-amd64.tar.gz`, version `v1.0.0-tb1`, file `vault-plugin-secrets-nexus-repository_v1.0.0-tb1.intoto.jsonl` also has to be downloaded from the release): +```sh +$ slsa-verifier verify-artifact \ + --source-uri manhtukhang/vault-plugin-secrets-nexus-repository \ + --source-tag v1.0.0-tb1 \ + --provenance-path ./vault-plugin-secrets-nexus-repository_v1.0.0-tb1.intoto.jsonl \ + ./vault-plugin-secrets-nexus-repository_v1.0.0-tb1_linux-amd64.tar.gz +``` +```console +Verifying vault-plugin-secrets-nexus-repository_v0.0.1-tb1_linux-amd64.tar.gz with slsa-verifier +Verified signature against tlog entry index 155157774 at URL: https://rekor.sigstore.dev/api/v1/log/entries/108e9186e8c5677aeda7d7a4c8fb7cdb79ecaab29fe4441d8d5bd887e2e8df15d685c84350e21035 +Verified build using builder "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v2.0.0" at commit 067f1fc9064d7d78d673925f78d0f81bb84c6637 +Verifying artifact vault-plugin-secrets-nexus-repository_v0.0.1-tb1_linux-amd64.tar.gz: PASSED + +PASSED: SLSA verification passed +``` + +#### Using GitHub CLI + +Follow this [installation instruction](https://github.com/cli/cli#installation) to install GitHub CLI (`gh` command). + +Verify (e.g for the `vault-plugin-secrets-nexus-repository_v0.0.1-tb1_linux-amd64.tar.gz`): +```sh +$ gh attestation verify \ + --repo manhtukhang/vault-plugin-secrets-nexus-repository \ + ./vault-plugin-secrets-nexus-repository_v0.0.1-tb1_linux-amd64.tar.gz +``` +```console +Loaded digest sha256:815378c1be24539758452a232bb10510fb89dc562cbd1c8cd5e5746847670b58 for file://vault-plugin-secrets-nexus-repository_v0.0.1-tb1_linux-amd64.tar.gz +Loaded 1 attestation from GitHub API +✓ Verification succeeded! + +sha256:815378c1be24539758452a232bb10510fb89dc562cbd1c8cd5e5746847670b58 was attested by: +REPO PREDICATE_TYPE WORKFLOW +manhtukhang/vault-plugin-secrets-nexus-repository https://slsa.dev/provenance/v1 .github/workflows/release.yaml@refs/tags/v0.0.1-tb1 +``` + +> [!NOTE] +> Artifact attestations can be verified from a machine without the internet connection, please follow [this step-by-step guide](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/verifying-attestations-offline). + + --- ## ROADMAP