OpenDocket — vault

Compliance Risk Analysis

vault

https://github.com/hashicorp/vault
Scanned 2026-03-23 · OpenDocket V1 · Primary: Claude Sonnet · Review: Gemini 2.5 Flash

Important Limitations of This Report

This report is not legal advice and is not defensible in court. It provides directional guidance only. To obtain a defensible compliance assessment, engage a licensed attorney and certified auditor.

Scope limitations: Only public repository content was analyzed. Infrastructure configuration, deployment settings, operational policies, vendor contracts, and staff training are outside scope.

A true compliance audit would also review: vendor contracts and BAAs, staff training records, incident response procedures, physical security controls, and system audit logs — none of which are visible in source code.

Risk Assessment

This analysis identified 56 compliance patterns across GDPR, HIPAA, PCI-DSS, SOC2, SOX, TCPA. After independent verification by Gemini 2.5 Flash, 5 high-severity findings were confirmed and 50 were identified as possible false positives — likely pattern matches in documentation or configuration files rather than application source code. The 5 confirmed findings represent the primary areas requiring attention.

ELEVATED RISK

5 confirmed high-severity findings
45 total patterns identified · 50 flagged as possible false positives by independent review

What This Means If Unaddressed

Framework	Regulatory Body	Max Penalty	Enforcement Trend
HIPAA (9 high)	HHS / OCR	Fines up to $1.5M/year per category	Increasing enforcement, record penalties in 2024
GDPR (9 high)	EU DPAs	Up to EUR 20M or 4% turnover	Cross-border enforcement rising
TCPA (8 high)	FCC	$500-$1,500 per violation	Class action filings at record levels
SOX (7 high)	SEC / PCAOB	Criminal penalties, delisting	IT controls under increased scrutiny
SOC2 (6 high)	AICPA	Loss of enterprise contracts	Mandatory for enterprise SaaS sales
PCI-DSS (6 high)	PCI SSC	Fines $5K-$100K/month	v4.0 enforcement accelerating

Top Findings

High RiskGDPRGDPR-009CHANGELOG-v0.md:23 · Review: CONFIRMED

Conduct a formal Data Protection Impact Assessment as required under GDPR Article 35 for this high-risk data processing system. Document the DPIA findings, risk mitigation measures, and compliance con

High RiskPCI-DSSPCIDSS-008.build/entrypoint.sh:44 · Review: CONFIRMED

The system requires implementation of comprehensive cryptographic key management procedures that explicitly address all PCI DSS requirements including secure key generation algorithms, encrypted distr

High RiskSOC2SOC2-005.build/entrypoint.sh:49 · Review: CONFIRMED

Implement formal change management controls including: mandatory pull request reviews with approval requirements before merging code changes, documented deployment procedures with approval gates for p

Gemini Verification Layer

How to read this: The confirmed count is your action list. The false positive count shows where the scanner found keyword patterns in documentation rather than application source code. Click any finding to see exactly what evidence was found and why Gemini made its determination.

6Confirmed

0Context dependent

50Possible false positives

0Additional risk

Primary: Claude Sonnet (Anthropic). Verification: Gemini 2.5 Flash (Google). Neither constitutes legal advice.

Recommended Actions

High

For the capabilities described in `Makefile:62-64` (memory profiling) and the features documented in `CHANGELOG-v0.md:23`, `changelog/12422.txt:2`, and `changelog/25636.txt:2` (various forms of tracking), conduct a formal Data Protection Impact Assessment (DPIA). Document the DPIA findings and risk mitigation measures to comply with GDPR Article 35, which mandates DPIAs for high-risk data processing activities.

GDPR · GDPR-009 · Confirmed

High

Verify that the cryptographic key management procedures for Vault's Raft storage backend, referenced in `enos/modules/k8s_deploy_vault/raft-config.hcl`, and built-in credential engines (e.g., AWS, GitHub, as indicated by `.github/CODEOWNERS`), including key generation, distribution, storage, rotation, and destruction, are fully documented and implemented consistent with PCI DSS Requirements 3.6 and 3.7 to avoid severe audit findings.

PCI-DSS · PCIDSS-008 · Confirmed

High

Establish mandatory pull request reviews and approval requirements for changes to `.build/entrypoint.sh`, `.build/go.sh`, and `.copywrite.hcl`. This ensures all modifications to build processes and configuration are formally reviewed and approved, thereby preventing uncontrolled changes to critical system components as required by SOC2 CC8.1.

SOC2 · SOC2-005 · Confirmed

High

Formal security policies for acceptable use, data classification, and access management are absent from the repository, with files such as `CONTRIBUTING.md` and `.github/CODE_OF_CONDUCT.md` not fulfilling this requirement. New policy documents must be created and stored in an accessible location, as mandated by SOC2 CC1.1 for demonstrating ethical values and integrity.

SOC2 · SOC2-010 · Confirmed

High

Clarify and document the role-based access controls (RBAC) and approval procedures for `@hashicorp/github-secure-vault-core` and `@hashicorp/team-vault-quality` defined in `.github/CODEOWNERS` for changes to `.github/workflows/build.yml`. This ensures stringent authorization of personnel involved in the financial system's deployment, addressing SOX Section 404 internal control requirements.

SOX · SOX-002 · Confirmed

+ 1 more recommendations in the Findings tab

Risk Scorecard

Framework	High Risk	Confirmed	False Pos.	Medium	Concern	No Issue
GDPR	9	1	9	0	1	0
HIPAA	9	0	10	0	1	0
PCI-DSS	6	2	8	2	1	1
SOC2	6	2	8	2	2	0
SOX	7	1	7	1	0	0
TCPA	8	0	8	0	0	0

Domains Detected

Saas

75.0%

Ecommerce

44.2%

Communication

32.3%

Fintech

24.9%

Healthcare

14.8%

Gdpr

12.5%

HIPAA

HHS / OCR · Fines up to $1.5M/year per category

10 findings · 10 possible FP

Possible False Positives (10)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

HIPAA-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of generic documentation files and a CI/CD test configuration file, none of which directly demonstrate the collection, storage, processing, or transmission of PHI or a specific failure in technical safeguards for PHI.

Evidence

[DOCS] .github/instructions/generic/code_comments.instructions.md:8 ## General Philosophy [DOCS] .github/instructions/generic/code_comments.instructions.md:8 ## General Philosophy [DOCS] .github/instructions/generic/testing.instructions.md:6 # Philosophy & Principles [DOCS] .github/instructions/generic/testing.instructions.md:6 # Philosophy & Principles [CONFIG] .github/workflows/test-go.yml:355 chmod a+rx runsc containerd-shim-runsc-v1 [DOCS] CHANGELOG-v0.md:187 AES operations in its cryptographic barrier. Specifically, this means that [DOCS] CHANGELOG-v0.md:359 validation (in addition to the cryptographic signature) and a user and [DOCS] CHANGELOG-v0.md:2548 and uses the cryptographically signed dynamic metadata information that

Finding

Does this system collect, store, process, or transmit individually identifiable health information as defined under 45 CFR §160.103, and if so, are adequate technical safeguards in place to protect the confidentiality of such Protected Health Information?

Remediation

Add specific instructions within `.github/instructions/generic/code_comments.instructions.md` and `.github/instructions/generic/testing.instructions.md` on how to identify and protect PHI, aligning with HIPAA's definition of individually identifiable health information under 45 CFR §160.103 and general technical safeguard requirements under 45 CFR §164.306(a).

HIPAA-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists entirely of configuration files (`.sh`, `.hcl`, `.github/CODEOWNERS`) and not application source code, thus, according to mandatory decision rules, this finding is a possible false positive.

Evidence

[CONFIG] .build/entrypoint.sh:44 # Assume that /build is where we've mounted the vault repo. [CONFIG] .copywrite.hcl:16 "enos/modules/k8s_deploy_vault/raft-config.hcl", [CONFIG] .github/CODEOWNERS:72 # Cryptosec [CONFIG] .github/CODEOWNERS:73 /api/auth/cert/ @hashicorp/vault-crypto [CONFIG] .github/CODEOWNERS:74 /builtin/logical/pki/ @hashicorp/vault-crypto [CONFIG] .github/CODEOWNERS:75 /builtin/logical/pkiext/ @hashicorp/vault-crypto [CONFIG] .github/CODEOWNERS:76 /website/content/docs/secrets/pki/ @hashicorp/vault-crypto @hashicorp/vault-educat [CONFIG] .github/CODEOWNERS:77 /website/content/api-docs/secret/pki/ @hashicorp/vault-crypto @hashicorp/vault-educat

Finding

Is electronic Protected Health Information encrypted when stored at rest using methods consistent with NIST Special Publication 800-111, as required for addressable implementation under the HIPAA Security Rule?

Remediation

Review the `raft-config.hcl` (referenced in `.copywrite.hcl`) and associated Vault storage backend configurations to confirm that any ePHI stored at rest by Vault utilizes encryption mechanisms consistent with NIST SP 800-111, preventing HIPAA Security Rule violations.

HIPAA-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of build-time configuration files (.sh scripts) demonstrating secure practices (HTTPS for external resource downloads and Git operations, installation of CA certificates) for the build environment, not direct application source code or configurations related to the application's runtime transmission of Protected Health Information.

Evidence

[CONFIG] .build/entrypoint.sh:22 # https://packages.ubuntu.com/search?suite=noble&section=all&arch=any&keywords=linux-gnu-gcc&searcho [CONFIG] .build/entrypoint.sh:46 git config --global url."https://${GITHUB_TOKEN}@github.com".insteadOf "https://github.com" [CONFIG] .build/go.sh:8 curl -L "https://go.dev/dl/go${GO_VERSION}.linux-${host_arch}.tar.gz" | tar -C /opt -zxv [CONFIG] .build/system.sh:14 # https://packages.ubuntu.com/search?suite=noble&section=all&arch=any&keywords=crossbuild-essential& [CONFIG] .build/system.sh:20 ca-certificates \ [CONFIG] .build/system.sh:20 ca-certificates \ [CONFIG] .github/CODEOWNERS:5 # More on CODEOWNERS files: https://help.github.com/en/github/creating-cloning-and-archiving-reposit [CONFIG] .github/CODEOWNERS:95 /sdk/helper/tlsutil/ @hashicorp/vault-crypto

Finding

Are all transmissions of electronic Protected Health Information encrypted using transport-level security consistent with NIST guidelines, preventing unauthorized access during transmission across electronic communications networks?

Remediation

The `.build/entrypoint.sh` and `.build/go.sh` scripts already utilize HTTPS for external resource fetching, and `.build/system.sh` includes `ca-certificates`, indicating secure transport practices for build processes. No specific changes are required in these files to ensure encryption in transit for PHI, as their current functions involve encrypted connections, thus meeting secure communication expectations for build operations.

HIPAA-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of configuration files related to repository access (`GITHUB_TOKEN` in build scripts) and code ownership (`CODEOWNERS` mentioning authentication methods), which does not directly demonstrate the implementation or absence of technical access control policies for Protected Health Information within the Vault application's runtime system as per the legal question.

Evidence

[CONFIG] .build/entrypoint.sh:13 [[ -z "$GITHUB_TOKEN" ]] && fail "A GITHUB_TOKEN has not been defined" [CONFIG] .build/entrypoint.sh:46 git config --global url."https://${GITHUB_TOKEN}@github.com".insteadOf "https://github.com" [CONFIG] .github/CODEOWNERS:53 # UI code related to Vault's JWT/OIDC auth method and OIDC provider. [CONFIG] .github/CODEOWNERS:56 /ui/app/components/auth/form/oidc-jwt.ts @hashicorp/vault-ui @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:27 # Identity Integrations (OIDC, tokens) [CONFIG] .github/CODEOWNERS:57 /ui/app/components/auth/form/saml.ts @hashicorp/vault-ui @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:12 /builtin/credential/ldap/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:10 /builtin/credential/aws/ @hashicorp/vault-ecosystem

Finding

Does the system implement technical policies and procedures for electronic information systems that maintain electronic Protected Health Information to allow access only to those persons or software programs that have been granted access rights as specified in 45 CFR §164.312(a)(1)?

Remediation

Verify that `ui/app/components/auth/form/oidc-jwt.ts`, as indicated in `.github/CODEOWNERS`, contains robust technical policies and procedures for OIDC/JWT authentication and authorization. Specifically, confirm that it ensures only granted access rights permit interaction with electronic Protected Health Information, thereby adhering to 45 CFR §164.312(a)(1).

HIPAA-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation and a workflow configuration, which do not directly demonstrate the presence or absence of electronic session termination procedures in the application's source code, making it an unlikely source of a session management vulnerability related to HIPAA.

Evidence

[DOCS] .github/instructions/generic/ember_js.instructions.md:85 - Avoid `setTimeout` in favor of `requestAnimationFrame` for UI updates or proper async patterns for [DOCS] .github/instructions/generic/ember_js.instructions.md:86 - **Warning**: `setTimeout` is prone to testing issues and event loop management problems [DOCS] .github/instructions/generic/ember_tests.instructions.md:86 - Use Ember's `run.later` instead of `setTimeout` in tests for better runloop control [DOCS] .github/instructions/generic/golang.instructions.md:130 - Use context for cancellation and timeouts [CONFIG] .github/workflows/mend-pr-scan.yml:33 scan-timeout-minutes: "30" [CONFIG] .github/workflows/test-ci-cleanup.yml:42 timeout-minutes: 120 [CONFIG] .github/workflows/test-enos-scenario-ui.yml:69 timeout-minutes: 90 [CONFIG] .github/workflows/test-enos-scenario-ui.yml:142 run: enos scenario launch --timeout 60m0s --chdir ./enos ui edition:${{ needs.get-metadata.outputs.v

Finding

Does the system implement electronic procedures that terminate an electronic session after a predetermined time of inactivity, as required for PHI-accessing interfaces under the HIPAA Security Rule?

Remediation

The cited files, such as `.github/instructions/generic/ember_js.instructions.md` and `.github/workflows/mend-pr-scan.yml`, are documentation or scan configuration, not application source code for session management. Therefore, no specific changes are required in these particular files to address the electronic session termination requirements of HIPAA-005, as the evidence does not demonstrate non-compliance within these documents.

HIPAA-006 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of developer documentation and a configuration script for debug logging, which are not direct indicators of the application's actual implementation or lack thereof of HIPAA-compliant audit controls for ePHI.

Evidence

[DOCS] .github/instructions/generic/ember_js.instructions.md:95 ## Error Handling and Logging [DOCS] .github/instructions/generic/ember_js.instructions.md:97 - Avoid `console.error` in production code - use proper logging libraries or framework-specific meth [DOCS] .github/instructions/generic/ember_js.instructions.md:99 - Use structured logging with consistent log levels (debug, info, warn, error) [DOCS] .github/pull_request_template.md:16 Examples of changes to security controls include using new access control methods, adding or removin [CONFIG] .github/scripts/install-cob.sh:13 -d turns on debug logging [CONFIG] .github/scripts/install-cob.sh:378 # use in logging routines [DOCS] CHANGELOG-v0.md:8 * replication/perfstandby: Fix audit table upgrade on standbys [[GH-5811](https://github.com/hashico [DOCS] CHANGELOG-v0.md:443 * In the audit log and in client responses, policies are now split into three

Finding

Does the system implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic Protected Health Information, as required under the audit controls standard?

Remediation

Update the logging instructions in `.github/instructions/generic/ember_js.instructions.md` to explicitly cover HIPAA audit logging requirements for ePHI, including user authentication and data access patterns. Ensure `vault`'s audit backends are robustly configured to capture these events, clarifying that debug logging from `.github/scripts/install-cob.sh` is insufficient for HIPAA-006 compliance.

HIPAA-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation files and build action configurations, which do not contain or control access to Protected Health Information (PHI) and are therefore irrelevant to the 'Minimum Necessary Access' standard under HIPAA.

Evidence

[DOCS] .github/ISSUE_TEMPLATE.md:10 <!-- Uncomment this section if this is a feature request. Include or exclude other sections as deeme [DOCS] .github/ISSUE_TEMPLATE/plugin-submission.md:10 Please provide details for the plugin to be listed. All fields are required for a submission to be i [CONFIG] .github/actions/build-vault/action.yml:104 docker_sha=$(git ls-tree HEAD Dockerfile --object-only --abbrev=5) [CONFIG] .github/actions/build-vault/action.yml:105 build_sha=$(git ls-tree HEAD .build --object-only --abbrev=5) [CONFIG] .github/actions/build-vault/action.yml:106 tools_sha=$(git ls-tree HEAD tools/tools.sh --object-only --abbrev=5) [CONFIG] .github/actions/build-vault/action.yml:107 github_sha=$(git ls-tree HEAD .github/actions/build-vault --object-only --abbrev=5) [CONFIG] .github/actions/build-vault/action.yml:153 # Only build a container for the host OS since the same container [CONFIG] .github/actions/build-vault/action.yml:175 # Only build a container for the host OS since the same container

Finding

Does the system limit the Protected Health Information disclosed or accessed to the minimum necessary to accomplish the intended purpose, consistent with the minimum necessary standard under the Privacy Rule?

Remediation

No modifications are necessary within the cited `.github/ISSUE_TEMPLATE.md` or `.github/actions/build-vault/action.yml` files, as these documentation and build configuration files do not govern PHI access controls, thereby ensuring appropriate focus on actual HIPAA Minimum Necessary Standard implementation points.

HIPAA-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited (build scripts for s390x cross-compilation and git attribute configuration) has no logical connection to third-party integrations, Protected Health Information, or Business Associate Agreement requirements.

Evidence

[CONFIG] .build/entrypoint.sh:30 s390x) [CONFIG] .build/entrypoint.sh:31 export CC=s390x-linux-gnu-gcc [CONFIG] .build/system.sh:18 gcc-s390x-linux-gnu \ [CONFIG] .build/system.sh:19 crossbuild-essential-s390x \ [CONFIG] .gitattributes:1 vendor/* linguist-vendored [CONFIG] .github/CODEOWNERS:27 # Identity Integrations (OIDC, tokens) [CONFIG] .github/CODEOWNERS:10 /builtin/credential/aws/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:16 /builtin/logical/aws/ @hashicorp/vault-ecosystem

Finding

Does the system integrate with third-party services that may receive, maintain, or transmit Protected Health Information, and if so, is there evidence that Business Associate Agreement requirements are addressed in the code or configuration?

Remediation

Modify .build/entrypoint.sh or .build/system.sh to include a check or flag that ensures Business Associate Agreements are validated before enabling any third-party services that may process Protected Health Information, thereby complying with HIPAA-008 standards.

HIPAA-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of GitHub Actions configuration files and general documentation, which do not directly demonstrate issues with PHI data retention and disposal policies as described in the HIPAA-009 standard.

Evidence

[CONFIG] .github/actions/build-vault/action.yml:75 enableCrossOsArchive: true [CONFIG] .github/actions/build-vault/action.yml:138 driver-opts: network=host # So we can run our own little registry [CONFIG] .github/actions/create-dynamic-config/action.yml:31 # If/when Github decides to purge our tiny config file cache we'll also [CONFIG] .github/actions/set-up-go/action.yml:68 enableCrossOsArchive: true [DOCS] .github/instructions/generic/code_comments.instructions.md:154 - Delete comments that are no longer relevant [DOCS] .github/instructions/generic/code_comments.instructions.md:248 - **Update** or delete comments when code changes [DOCS] .github/instructions/generic/golang.instructions.md:98 - Use `delete(m, key)` to remove entries safely [DOCS] .github/instructions/generic/golang.instructions.md:41 - Use defer for cleanup operations (closing files, unlocking mutexes)

Finding

Does the system implement policies and procedures to address the final disposition of electronic Protected Health Information and the hardware or electronic media on which it is stored, as well as removal of PHI before media is available for reuse?

Remediation

Formalize retention and disposal policies for build artifacts generated by `.github/actions/build-vault/action.yml` and `.github/actions/set-up-go/action.yml` (specifically for any data managed with `enableCrossOsArchive: true`) and caches handled via `.github/actions/create-dynamic-config/action.yml`, to securely remove any potentially included PHI and avoid non-compliance with HIPAA data disposition requirements.

HIPAA-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of CI/CD configuration files related to code ownership notifications and build caching, which do not directly pertain to or provide evidence for system procedures regarding breach detection, incident response, or emergency access to PHI as required by HIPAA-010.

Evidence

[CONFIG] .github/CODEOWNERS:55 # so stewards of the backend code are added below for notification. [CONFIG] .github/actions/build-vault/action.yml:71 - name: Restore UI from cache [CONFIG] .github/actions/build-vault/action.yml:74 # Restore the UI asset from the UI build workflow. Never use a partial restore key. [CONFIG] .github/actions/create-dynamic-config/action.yml:40 - name: Try to restore dynamic config from cache [CONFIG] .github/actions/create-dynamic-config/action.yml:48 # If we can't restore it from config then set up pipeline and generate it [CONFIG] .github/actions/install-tools/action.yml:8 possible we'll restore the tools from prior build that was cached. On a cache [CONFIG] .github/actions/install-tools/action.yml:9 miss we'll rebuild the tools. After the tools are restored the `cache-path` [CONFIG] .github/actions/install-tools/action.yml:13 no-restore:

Finding

Does the system implement procedures for detecting, reporting, and responding to suspected or known security incidents involving electronic Protected Health Information, and does it provide for emergency access to PHI during system disruptions?

Remediation

The referenced `.github/CODEOWNERS` and `.github/actions/*.yml` files pertain to code ownership notifications and CI/CD caching, which are not relevant to HIPAA-010's requirements for incident response or emergency PHI access, therefore no changes are needed in these specific files to address this finding under HIPAA.

PCI-DSS

PCI SSC · Fines $5K-$100K/month

10 findings · 8 possible FP

PCIDSS-008

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The finding correctly identifies a high-risk compliance area for the 'vault' repository, a dedicated key management system, regarding PCI-DSS key management practices. Although the evidence cites configuration files, these files are integral to the system's core functionality (e.g., Raft storage, credential engines), making the question of key management procedures highly relevant and not a false positive.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .build/entrypoint.sh:44 # Assume that /build is where we've mounted the vault repo. [CONFIG] .copywrite.hcl:16 "enos/modules/k8s_deploy_vault/raft-config.hcl", [CONFIG] .github/CODEOWNERS:7 * @hashicorp/vault [CONFIG] .github/CODEOWNERS:10 /builtin/credential/aws/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:11 /builtin/credential/github/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:12 /builtin/credential/ldap/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:13 /builtin/credential/okta/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:16 /builtin/logical/aws/ @hashicorp/vault-ecosystem

Finding

Does the system implement cryptographic key management procedures including key generation, distribution, storage, rotation, and destruction, consistent with PCI DSS Requirement 3.6 and 3.7?

Remediation

Remediation refined by Gemini review

PCIDSS-006

Medium Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The evidence, though documentation and config, explicitly details development practices focused on linting and formatting, which are insufficient to meet PCI-DSS requirements for comprehensive security testing (SAST, DAST, penetration testing, security-focused code review), thus confirming the identified gap in controls.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[DOCS] .github/instructions/generic/ember_general.instructions.md:35 - **Development**: ESLint for code linting, Prettier for code formatting [DOCS] .github/instructions/generic/ember_general.instructions.md:35 - **Development**: ESLint for code linting, Prettier for code formatting [DOCS] .github/instructions/generic/golang.instructions.md:138 - Understand escape analysis and stack vs heap allocation [DOCS] .github/instructions/generic/golang.instructions.md:155 - Understand escape analysis and stack vs heap allocation [CONFIG] .github/workflows/actionlint.yml:1 name: Lint GitHub Actions Workflows [CONFIG] .github/workflows/actionlint.yml:14 actionlint: [CONFIG] .github/workflows/actionlint.yml:18 - name: "Run actionlint" [CONFIG] .github/workflows/actionlint.yml:20 docker run --rm -v "$(pwd):/repo" --workdir /repo docker.mirror.hashicorp.services/rhysd/actionlint@

Finding

Does the system implement security testing controls including code review, static analysis, and penetration testing practices, as required under PCI DSS Requirement 6.3 and 11.4?

Remediation

Update `.github/instructions/generic/ember_general.instructions.md` and `.github/instructions/generic/golang.instructions.md` to detail mandatory security code reviews, security-focused SAST tools, DAST, and penetration testing practices, moving beyond basic linting, to comply with PCI DSS Requirements 6.3 and 11.4.

Remediation refined by Gemini review

Possible False Positives (8)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

PCIDSS-001 · Possible False Positive

No Issue Found›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The primary analysis identified 'No Issue Found' and the evidence consists solely of documentation and configuration files, not application source code that would directly store, process, or transmit cardholder data, indicating the patterns cited are not direct PCI-DSS risks.

Evidence

[DOCS] .github/instructions/generic/ember_js.instructions.md:115 @tracked isExpanded = false; [DOCS] .github/instructions/generic/golang.instructions.md:86 - Use panic only for truly exceptional cases or programming errors [DOCS] .github/instructions/generic/golang.instructions.md:87 - Use recover to handle panics gracefully in server applications [CONFIG] .github/workflows/test-ci-cleanup.yml:54 mask-aws-account-id: false [CONFIG] .github/workflows/test-go.yml:183 # enable glob expansion [CONFIG] .github/workflows/test-go.yml:192 # disable glob expansion [DOCS] CHANGELOG-v0.md:24 * cli: Fix panic that could occur if parameters were not provided [[GH-5603](https://github.com/hash [DOCS] CHANGELOG-v0.md:99 * auth/ldap: Fix panic if specific values were given to be escaped [[GH-5471](https://github.com/has

Finding

Does this system store, process, or transmit cardholder data including primary account numbers (PAN), and if so, are adequate protections in place to render stored PAN unreadable, as required under PCI DSS Requirement 3.5?

Remediation

While the instructions in `.github/instructions/generic/ember_js.instructions.md` and `.github/instructions/generic/golang.instructions.md`, and configuration files like `.github/workflows/test-ci-cleanup.yml` and `.github/workflows/test-go.yml` do not currently indicate direct handling of cardholder data, should future modifications enable any of these components to handle Primary Account Numbers (PAN), apply strong encryption to render stored PAN unreadable and establish proper key management, or risk non-compliance with PCI DSS Requirement 3.5.

PCIDSS-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of build configuration scripts, and the specific lines referenced do not contain application logic related to handling, storing, or transmitting cardholder data, thus not demonstrating a PCI DSS encryption deficiency.

Evidence

[CONFIG] .build/entrypoint.sh:44 # Assume that /build is where we've mounted the vault repo. [CONFIG] .build/entrypoint.sh:22 # https://packages.ubuntu.com/search?suite=noble&section=all&arch=any&keywords=linux-gnu-gcc&searcho [CONFIG] .build/entrypoint.sh:46 git config --global url."https://${GITHUB_TOKEN}@github.com".insteadOf "https://github.com" [CONFIG] .build/go.sh:8 curl -L "https://go.dev/dl/go${GO_VERSION}.linux-${host_arch}.tar.gz" | tar -C /opt -zxv [CONFIG] .build/system.sh:14 # https://packages.ubuntu.com/search?suite=noble&section=all&arch=any&keywords=crossbuild-essential& [CONFIG] .build/system.sh:20 ca-certificates \ [CONFIG] .copywrite.hcl:16 "enos/modules/k8s_deploy_vault/raft-config.hcl", [CONFIG] .github/CODEOWNERS:72 # Cryptosec

Finding

Is cardholder data encrypted using strong cryptography during transmission over open public networks and when stored at rest, consistent with PCI DSS Requirements 3.5 and 4.2?

Remediation

The build scripts in `.build/entrypoint.sh` and `.build/go.sh` already utilize HTTPS for `git config` and `curl` operations, demonstrating adherence to secure transmission protocols. Therefore, no changes are required in these specific files to address PCI DSS Requirement 4.2 for data in transit over public networks.

PCIDSS-003 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The finding is based solely on documentation files discussing access control concepts, not actual application source code demonstrating a failure to restrict access to cardholder data.

Evidence

[DOCS] .github/instructions/generic/code_comments.instructions.md:108 if (user.role === 'admin' && user.status === 'active' && !user.suspended) { ... } [DOCS] .github/instructions/generic/code_comments.instructions.md:112 user.role === 'admin' && user.status === 'active' && !user.suspended; [DOCS] .github/instructions/generic/code_comments.instructions.md:107 // Check if user has admin permissions and is active [DOCS] .github/instructions/generic/ember_general.instructions.md:59 "ui (enterprise): Add advanced policy filtering" // enterprise features [DOCS] .github/instructions/generic/ember_hbs.instructions.md:26 {{#if this.model.allowed_roles}} [DOCS] .github/instructions/generic/ember_hbs.instructions.md:29 {{#if (gt this.model.allowed_roles.length 0)}} [DOCS] .github/instructions/generic/ember_hbs.instructions.md:32 @secret="role/{{@model.id}}" [DOCS] .github/instructions/generic/ember_hbs.instructions.md:35 @secret={{concat "role/" @model.id}}

Finding

Does the system restrict access to cardholder data to only those individuals and systems whose job requires such access, implementing role-based access controls consistent with PCI DSS Requirement 7?

Remediation

Review the application's source code, specifically around logic related to cardholder data access, to confirm that granular, role-based access controls are explicitly enforced, going beyond the conceptual discussions in `.github/instructions/generic/code_comments.instructions.md` and `.github/instructions/generic/ember_hbs.instructions.md`. This verification is critical for compliance with PCI DSS Requirement 7, ensuring only authorized personnel can access cardholder data.

PCIDSS-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of GitHub Actions workflow configuration files and documentation, which discuss general VPC limits and firewall behavior for connection stability, not the implementation or absence of network segmentation for a Cardholder Data Environment (CDE) as required by PCI DSS Requirement 1.

Evidence

[CONFIG] .github/workflows/build.yml:48 # accidentally regress. [CONFIG] .github/workflows/test-ci-cleanup.yml:91 # Currently just checking VPC limits across all region, can add more checks here in future [CONFIG] .github/workflows/test-ci-cleanup.yml:93 run: awslimitchecker -S "VPC" -r ${{matrix.region}} [DOCS] CHANGELOG-v0.md:1779 connections from being terminated by firewalls or proxies [DOCS] CHANGELOG-v0.md:1873 * replication: Add heartbeating to ensure firewalls don't kill connections to [DOCS] CHANGELOG-v0.md:1638 list of authorized addresses (IPs or subnets) can be defined and [DOCS] CHANGELOG-v0.md:1988 Subnet ID and Region [GH-2407] [DOCS] CHANGELOG-v0.md:1987 * auth/aws-ec2: AWS EC2 auth backend now supports constraints for VPC ID,

Finding

Does the system implement network segmentation to isolate the cardholder data environment (CDE) from other network segments, reducing the scope of PCI DSS compliance as described in Requirement 1?

Remediation

The cited evidence in `.github/workflows/` and `CHANGELOG-v0.md` does not relate to the configuration of network segmentation for a Cardholder Data Environment (CDE), therefore no changes are required within these specific files to address PCI DSS Requirement 1. Instead, verify your actual cloud infrastructure configurations (e.g., AWS Security Groups, NACLs, VPC routing) for proper CDE isolation to ensure PCI DSS compliance.

PCIDSS-005 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited is a GitHub Actions configuration file (.yml) which orchestrates upgrade tests, not application source code or direct evidence of a lack of vulnerability management practices.

Evidence

[CONFIG] .github/actions/run-apupgrade-tests/action.yml:5 name: Run Autopilot upgrade tests [CONFIG] .github/actions/run-apupgrade-tests/action.yml:7 This action runs the Autopilot upgrade tests on Vault Enterprise. [CONFIG] .github/actions/run-apupgrade-tests/action.yml:9 from the Vault Enterprise repository, builds the target version binary of Vault for Autopilot upgrad [CONFIG] .github/actions/run-apupgrade-tests/action.yml:10 and runs the Autopilot upgrade tool with the specified source versions. [CONFIG] .github/actions/run-apupgrade-tests/action.yml:16 The target version binary of Vault for Autopilot upgrade testing will be built from this checkout. [CONFIG] .github/actions/run-apupgrade-tests/action.yml:24 The source versions of Vault for Autopilot upgrade testing as a comma-separated string, [CONFIG] .github/actions/run-apupgrade-tests/action.yml:69 - name: Checkout Vault tools repository to get the Autopilot upgrade tool [CONFIG] .github/actions/run-apupgrade-tests/action.yml:97 # for apupgrade to use as a target version

Finding

Does the system demonstrate evidence of vulnerability management practices including regular patching, dependency updates, and vulnerability scanning, consistent with PCI DSS Requirement 6?

Remediation

To more fully demonstrate PCI DSS Requirement 6 compliance for vulnerability management, modify or extend CI/CD workflows, such as the one in `.github/actions/run-apupgrade-tests/action.yml`, to explicitly integrate automated vulnerability scanning and dependency analysis steps before building and running upgrade tests. This ensures that new versions and dependencies are continuously checked for security flaws, helping to prevent the deployment of vulnerable code that could lead to a compromise of cardholder data.

PCIDSS-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation and a configuration script, which discuss general logging practices but do not demonstrate the actual implementation of specific audit trail mechanisms for cardholder data access or administrative privileges as required by PCI DSS Requirement 10.

Evidence

Finding

Does the system implement audit trail mechanisms that record all individual access to cardholder data, all actions taken by any individual with root or administrative privileges, and all access to audit trails, as required under PCI DSS Requirement 10?

Remediation

The existing `.github/instructions/generic/ember_js.instructions.md` currently provides general logging advice without specific details for audit trails related to cardholder data or administrative actions. Update this documentation to explicitly mandate and detail granular audit logging, including user identification and timestamps for all cardholder data access and administrative activities, ensuring compliance with PCI DSS Requirement 10.

PCIDSS-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration and documentation files, and does not concretely demonstrate that the identified third-party interactions (OIDC providers, plugins, vendored code) involve direct access to cardholder data, which is central to PCI DSS Requirement 12.8.

Evidence

[CONFIG] .gitattributes:1 vendor/* linguist-vendored [CONFIG] .github/CODEOWNERS:53 # UI code related to Vault's JWT/OIDC auth method and OIDC provider. [CONFIG] .github/CODEOWNERS:27 # Identity Integrations (OIDC, tokens) [DOCS] .github/ISSUE_TEMPLATE/plugin-submission.md:10 Please provide details for the plugin to be listed. All fields are required for a submission to be i [CONFIG] .github/actions/checkout/action.yml:7 Determine and checkout the correct Git reference depending on the actions event type and tags. [CONFIG] .github/actions/checkout/action.yml:10 checkout-head: [CONFIG] .github/actions/checkout/action.yml:13 `checkout-head` tag. [CONFIG] .github/actions/checkout/action.yml:33 # Determine our desired checkout ref and fetch depth. Depending our our workflow event

Finding

Does the system manage third-party service providers that have access to cardholder data with appropriate controls, agreements, and monitoring, consistent with PCI DSS Requirement 12.8?

Remediation

Formal written agreements, including due diligence for PCI DSS compliance and data access controls, must be established for third-party OIDC providers referenced in `.github/CODEOWNERS` (lines 27 and 53) and for any plugins derived from submissions via `.github/ISSUE_TEMPLATE/plugin-submission.md` (line 10) if they access or impact cardholder data, to meet PCI DSS Requirement 12.8 and avoid non-compliance.

PCIDSS-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration and documentation files showing generic alert and notification mechanisms, which do not confirm the presence or absence of a specific PCI DSS-compliant incident response plan for cardholder data breaches.

Evidence

[CONFIG] .github/CODEOWNERS:55 # so stewards of the backend code are added below for notification. [DOCS] .github/instructions/generic/ember_hbs.instructions.md:112 <Hds::Alert @message="Operation completed successfully" /> [DOCS] .github/instructions/generic/ember_tests.instructions.md:128 assert.ok(find('.alert-success')); [CONFIG] .github/scripts/install-cob.sh:170 1) echo "alert" ;; [CONFIG] .github/workflows/test-run-enos-scenario-matrix.yml:289 # Send slack notifications to #feed-vault-enos-failures any of our enos scenario commands fail. [CONFIG] .release/ci.hcl:9 notification_channel = "C09LD1XT5MX" // #feed-vault-releases [CONFIG] .release/ci.hcl:44 notification { [CONFIG] .release/ci.hcl:57 notification {

Finding

Does the system implement an incident response plan that addresses suspected or confirmed cardholder data breaches, including detection, containment, and notification procedures, as required under PCI DSS Requirement 12.10?

Remediation

Update the organizational incident response plan to clearly define notification procedures for cardholder data breaches, leveraging existing channels like those specified in `.github/CODEOWNERS` for backend stewards and `.github/workflows/test-run-enos-scenario-matrix.yml` for system alerts, to ensure PCI DSS Requirement 12.10 compliance.

SOC2

AICPA · Loss of enterprise contracts

10 findings · 8 possible FP

SOC2-005

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The identified risk pertains to change management controls over build scripts and critical configuration files, which are integral to the software's build and deployment lifecycle, making the absence of such controls a confirmed high-risk SOC2 violation.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .build/entrypoint.sh:49 cd build || exit 1 [CONFIG] .build/go.sh:8 curl -L "https://go.dev/dl/go${GO_VERSION}.linux-${host_arch}.tar.gz" | tar -C /opt -zxv [CONFIG] .copywrite.hcl:1 schema_version = 1 [CONFIG] .copywrite.hcl:16 "enos/modules/k8s_deploy_vault/raft-config.hcl", [CONFIG] .copywrite.hcl:20 "enos/.terraform/**", [DOCS] .github/ISSUE_TEMPLATE.md:15  [DOCS] .github/ISSUE_TEMPLATE.md:17 * Vault Version: [DOCS] .github/ISSUE_TEMPLATE/bug_report.md:31 * Vault Server Version (retrieve with `vault status`):

Finding

Does the system demonstrate evidence of change management controls including version control, code review processes, and controlled deployment procedures, as required under CC8.1 for managing changes to infrastructure, data, software, and procedures?

Remediation

Remediation refined by Gemini review

SOC2-010

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The primary analysis correctly identifies the absence of critical security policy documentation (acceptable use, data classification, access management) within the repository, a direct violation of SOC2 CC1.1, and the provided evidence does not fulfill these requirements.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[DOCS] .github/CODE_OF_CONDUCT.md:3 HashiCorp Community Guidelines apply to you when interacting with the community here on GitHub and c [CONFIG] .github/workflows/changelog-checker.yml:53 echo "Reference - https://github.com/hashicorp/vault/blob/main/CONTRIBUTING.md#changelog-entries" [DOCS] CONTRIBUTING.md:1 # Contributing to Vault [DOCS] ui/README.md:18 - [Contributing / Best Practices](#contributing--best-practices) [DOCS] ui/README.md:151 ### Contributing / Best Practices [DOCS] ui/README.md:153 Hello and thank you for contributing to the Vault UI! Below is a list of patterns we follow on the U [CONFIG] ui/app/components/app-footer.hbs:35 @text="Contributing docs" [CONFIG] ui/app/templates/docs.hbs:41 Contributing docs

Finding

Does the system demonstrate evidence of documented security policies, including acceptable use, data classification, and access management policies, as required under CC1.1 for the entity's commitment to integrity and ethical values?

Remediation

Remediation refined by Gemini review

Possible False Positives (8)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

SOC2-001 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files (`.build/entrypoint.sh` and `.github/CODEOWNERS`). While these files indicate the presence of credential-related modules and build-time authentication practices (GITHUB_TOKEN), they do not directly demonstrate the implementation, design, or operational effectiveness of user authentication controls within the Vault application itself as required by SOC2-001.

Evidence

[CONFIG] .build/entrypoint.sh:13 [[ -z "$GITHUB_TOKEN" ]] && fail "A GITHUB_TOKEN has not been defined" [CONFIG] .build/entrypoint.sh:46 git config --global url."https://${GITHUB_TOKEN}@github.com".insteadOf "https://github.com" [CONFIG] .github/CODEOWNERS:10 /builtin/credential/aws/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:11 /builtin/credential/github/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:12 /builtin/credential/ldap/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:13 /builtin/credential/okta/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:79 /builtin/credential/cert/ @hashicorp/vault-crypto [CONFIG] .github/CODEOWNERS:53 # UI code related to Vault's JWT/OIDC auth method and OIDC provider.

Finding

Does the system implement logical access security controls over user authentication that are suitably designed and operating effectively to restrict access to authorized users, consistent with the Common Criteria CC6.1 requirement for logical and physical access controls?

Remediation

Document the specific source code files and access procedures for the authentication modules referenced under `/builtin/credential/` in `.github/CODEOWNERS`. This improved transparency helps address SOC2-001 requirements for logical access security controls, as a lack of documented access to these implementations could lead to an audit finding.

SOC2-002 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of GitHub Actions configuration files related to the build process and a product description, which do not directly demonstrate the presence or absence of the application's runtime role-based access controls (RBAC) required by the SOC2 standard for system functions and data access.

Evidence

[CONFIG] .github/actions/build-vault/action.yml:230 description: Vault is a tool for secrets management, encryption as a service, and privileged access [CONFIG] .github/actions/build-vault/action.yml:161 cache-from: type=gha,scope=vault-builder-${{ steps.metadata.outputs.vault-builder-cache-key }} [CONFIG] .github/actions/build-vault/action.yml:162 cache-to: type=gha,mode=min,scope=vault-builder-${{ steps.metadata.outputs.vault-builder-cache-key } [CONFIG] .github/actions/build-vault/action.yml:183 cache-from: type=gha,scope=vault-builder-${{ steps.metadata.outputs.vault-builder-cache-key }} [CONFIG] .github/actions/build-vault/action.yml:184 cache-to: type=gha,mode=min,scope=vault-builder-${{ steps.metadata.outputs.vault-builder-cache-key } [DOCS] .github/instructions/generic/code_comments.instructions.md:108 if (user.role === 'admin' && user.status === 'active' && !user.suspended) { ... } [DOCS] .github/instructions/generic/code_comments.instructions.md:112 user.role === 'admin' && user.status === 'active' && !user.suspended; [DOCS] .github/instructions/generic/code_comments.instructions.md:107 // Check if user has admin permissions and is active

Finding

Does the system implement role-based or attribute-based access controls that restrict system functions and data access based on authorized user roles, consistent with the principle of least privilege as required under CC6.3?

Remediation

The evidence found in `.github/actions/build-vault/action.yml` configures CI/CD build caching and provides a product description, rather than implementing or validating application-level role-based access controls. Therefore, modifying these specific CI/CD configuration files will not address SOC2 CC6.3 requirements for restricting system functions and data access based on authorized user roles.

SOC2-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of build scripts, not application source code, and critically, the cited lines actively demonstrate the use and enforcement of HTTPS for external communications (e.g., GitHub, Go downloads) and the installation of `ca-certificates`, directly contradicting the finding of a high risk for a lack of encryption in transit.

Evidence

[CONFIG] .build/entrypoint.sh:22 # https://packages.ubuntu.com/search?suite=noble&section=all&arch=any&keywords=linux-gnu-gcc&searcho [CONFIG] .build/entrypoint.sh:46 git config --global url."https://${GITHUB_TOKEN}@github.com".insteadOf "https://github.com" [CONFIG] .build/go.sh:8 curl -L "https://go.dev/dl/go${GO_VERSION}.linux-${host_arch}.tar.gz" | tar -C /opt -zxv [CONFIG] .build/system.sh:14 # https://packages.ubuntu.com/search?suite=noble&section=all&arch=any&keywords=crossbuild-essential& [CONFIG] .build/system.sh:20 ca-certificates \ [CONFIG] .github/CODEOWNERS:5 # More on CODEOWNERS files: https://help.github.com/en/github/creating-cloning-and-archiving-reposit [CONFIG] .github/CODEOWNERS:95 /sdk/helper/tlsutil/ @hashicorp/vault-crypto [DOCS] .github/CODE_OF_CONDUCT.md:5 Please read the full text at https://www.hashicorp.com/community-guidelines

Finding

Does the system protect data during transmission over networks using encryption or other equivalent security measures, consistent with the CC6.7 requirement for protection of information during transmission?

Remediation

In build scripts like .build/entrypoint.sh and .build/go.sh, ensure all external resource fetching (e.g., git cloning, package downloads) consistently uses HTTPS, as exemplified by .build/entrypoint.sh:46 and .build/go.sh:8. This practice prevents unencrypted data transmission, aligning with SOC2 CC6.7 for protecting information during transmission.

SOC2-004 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation and a config file, which indicate guidance for logging but do not demonstrate the actual implementation of security event logging, monitoring, or alerting mechanisms in application source code.

Evidence

[CONFIG] .github/CODEOWNERS:55 # so stewards of the backend code are added below for notification. [DOCS] .github/instructions/generic/ember_hbs.instructions.md:112 <Hds::Alert @message="Operation completed successfully" /> [DOCS] .github/instructions/generic/ember_js.instructions.md:95 ## Error Handling and Logging [DOCS] .github/instructions/generic/ember_js.instructions.md:97 - Avoid `console.error` in production code - use proper logging libraries or framework-specific meth [DOCS] .github/instructions/generic/ember_js.instructions.md:99 - Use structured logging with consistent log levels (debug, info, warn, error) [DOCS] .github/instructions/generic/ember_tests.instructions.md:128 assert.ok(find('.alert-success')); [DOCS] .github/instructions/generic/testing.instructions.md:9 - Test coverage is not a metric to optimize for [DOCS] .github/pull_request_template.md:16 Examples of changes to security controls include using new access control methods, adding or removin

Finding

Does the system implement logging, monitoring, and alerting mechanisms that detect and record security events, anomalies, and unauthorized activities, as required under CC7.2 for monitoring system components for anomalies?

Remediation

Modify `.github/instructions/generic/ember_js.instructions.md` to explicitly include guidelines for logging security-relevant events, anomalies, and unauthorized activities, detailing what to log and how to structure these logs. This change is necessary to meet SOC2 CC7.2 requirements for monitoring system components for anomalies.

SOC2-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of documentation files related to dependency management practices and UI success messages, which do not directly demonstrate issues with incident detection, response, or recovery procedures as required by the SOC2 framework CC7.3 and CC7.4.

Evidence

[DOCS] .github/instructions/generic/ember_general.instructions.md:68 - Pin exact versions for critical dependencies or use tilde (`~`) for patch updates only [DOCS] .github/instructions/generic/ember_general.instructions.md:70 - Use tilde (`~`) for regular dependencies, exact versions for security-critical packages [DOCS] .github/instructions/generic/ember_general.instructions.md:81 "lodash": "4.17.21", // exact version for critical packages [DOCS] .github/instructions/generic/ember_hbs.instructions.md:112 <Hds::Alert @message="Operation completed successfully" /> [DOCS] .github/instructions/generic/ember_tests.instructions.md:128 assert.ok(find('.alert-success')); [DOCS] .github/pull_request_template.md:6 - [ ] **LTS**: If this fixes a critical security vulnerability or [severity 1](https://www.hashicorp [DOCS] .github/pull_request_template.md:6 - [ ] **LTS**: If this fixes a critical security vulnerability or [severity 1](https://www.hashicorp [CONFIG] .github/scripts/install-cob.sh:170 1) echo "alert" ;;

Finding

Does the system implement incident detection, response, and recovery procedures that enable timely identification and remediation of security incidents, consistent with CC7.3 requirements for evaluating security events and CC7.4 for responding to identified incidents?

Remediation

Create or update documentation within the `.github/instructions/generic/` directory (e.g., `incident_response.instructions.md`) to explicitly detail incident detection, response, and recovery procedures, mirroring the instructional format of `ember_general.instructions.md`. This will ensure the system comprehensively addresses SOC2 CC7.3 and CC7.4 requirements for security incident management.

SOC2-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence primarily cites configuration files (.hcl, .yml) and documentation (.md) related to dependency declaration and build setup, not application source code or direct proof of a missing risk management process, suggesting dependencies exist but not that their risks are unmanaged.

Evidence

[CONFIG] .copywrite.hcl:14 "ui/pnpm-lock.yaml", [CONFIG] .github/actions/setup-pnpm/action.yml:18 package_json_file: './ui/package.json' [CONFIG] .github/actions/setup-pnpm/action.yml:23 node-version-file: './ui/package.json' [CONFIG] .github/actions/setup-pnpm/action.yml:25 cache-dependency-path: ui/pnpm-lock.yaml [DOCS] .github/instructions/generic/code_comments.instructions.md:172 **Example - Block comments for context:** [DOCS] .github/instructions/generic/code_comments.instructions.md:179 const requestTypeName = constructTypeName(apiName, methodName); [DOCS] .github/instructions/generic/ember_general.instructions.md:67 ## package.json Guidelines [DOCS] .github/instructions/generic/ember_general.instructions.md:72 - Keep `package.json` changes minimal and focused on the specific feature or fix

Finding

Does the system assess and manage risks associated with third-party vendors, libraries, and service providers, including dependency vulnerability management, consistent with CC9.2 requirements for risk assessment of third-party service providers?

Remediation

Modify `.github/actions/setup-pnpm/action.yml` to integrate a dedicated step that performs automated dependency vulnerability scanning on `ui/pnpm-lock.yaml` and `ui/package.json`. This ensures continuous assessment and management of third-party library risks consistent with SOC2 CC9.2 requirements for risk assessment of third-party service providers.

SOC2-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence lines in `.build/entrypoint.sh` define compiler settings and check for build-time environment variables, which are entirely unrelated to data backup, replication, or recovery controls for SOC2-008.

Evidence

[CONFIG] .build/entrypoint.sh:25 export CC=x86_64-linux-gnu-gcc [CONFIG] .build/entrypoint.sh:28 export CC=aarch64-linux-gnu-gcc [CONFIG] .build/entrypoint.sh:31 export CC=s390x-linux-gnu-gcc [CONFIG] .build/entrypoint.sh:12 [[ -z "$GOARCH" ]] && fail "A GOARCH has not been defined" [CONFIG] .build/entrypoint.sh:13 [[ -z "$GITHUB_TOKEN" ]] && fail "A GITHUB_TOKEN has not been defined" [CONFIG] .build/entrypoint.sh:18 # We're building for a different architecture than our target host OS so [CONFIG] .build/entrypoint.sh:19 # we have to tell the Go compiler to use the correct C cross-compiler for [CONFIG] .build/entrypoint.sh:34 fail "Building for $GOARCH has not been implemented"

Finding

Does the system implement data backup, replication, and recovery controls that ensure availability and recoverability of data, consistent with the A1.2 criterion for recovery of infrastructure and data to meet objectives?

Remediation

The primary analysis misidentified build configuration settings in `.build/entrypoint.sh` as relevant to SOC2-008. No specific change is needed in `.build/entrypoint.sh` for data backup and recovery, as the file's purpose is unrelated to these controls. Non-compliance arises if actual application data lacks appropriate backup and recovery mechanisms.

SOC2-009 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence, consisting solely of configuration files and documentation, confirms the system's *support* for Multi-Factor Authentication (MFA) through references to TOTP functionality and an MFA flag; however, these files do not constitute direct proof of MFA *enforcement* for privileged accounts as required by SOC2 CC6.1, leading to a 'possible false positive' verdict based on the evidence type.

Evidence

[CONFIG] .github/CODEOWNERS:15 # Secrets engines (pki, ssh, totp and transit omitted) [CONFIG] .github/CODEOWNERS:15 # Secrets engines (pki, ssh, totp and transit omitted) [CONFIG] .github/workflows/oss.yml:32 - 'builtin/logical/totp/**' [CONFIG] .github/workflows/oss.yml:32 - 'builtin/logical/totp/**' [DOCS] CHANGELOG-v0.md:849 * command: Re-add `-mfa` flag and migrate to OSS binary [[GH-4223](https://github.com/hashicorp/vaul [DOCS] CHANGELOG-v0.md:852 * mfa: Invalidation of MFA configurations (Enterprise) [DOCS] CHANGELOG-v0.md:989 * **Okta Push support in Okta Auth Backend**: If a user account has MFA [DOCS] CHANGELOG-v0.md:990 required within Okta, an Okta Push MFA flow can be used to successfully

Finding

Does the system implement or support multi-factor authentication for user access, particularly for privileged accounts and administrative interfaces, consistent with CC6.1 requirements for logical access security?

Remediation

Provide explicit configuration examples or policy definitions within the repository, for instance within a `docs/security/` or `config/policy/` directory, that demonstrate MFA is configured and enforced for privileged access to the Vault system, leveraging features like `totp` as referenced in `.github/workflows/oss.yml`. Failure to demonstrate such enforcement may lead to non-compliance with SOC2 CC6.1 requirements.

SOX

SEC / PCAOB · Criminal penalties, delisting

8 findings · 7 possible FP

SOX-002

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The evidence, while consisting of configuration files, directly demonstrates the implementation of repository-level access controls (CODEOWNERS) for critical build workflows. For a system potentially handling financial data, these controls over the integrity of the build and deployment pipeline are essential aspects of 'Access Controls to Financial Systems' under SOX Section 404.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .github/CODEOWNERS:62 /.github/workflows/build.yml @hashicorp/github-secure-vault-core @hashicorp/team-vault-quality [CONFIG] .github/actions/build-vault/action.yml:74 # Restore the UI asset from the UI build workflow. Never use a partial restore key. [CONFIG] .github/actions/checkout/action.yml:33 # Determine our desired checkout ref and fetch depth. Depending our our workflow event [CONFIG] .github/actions/metadata/action.yml:5 name: Gather and export useful workflow metadata information. [CONFIG] .github/actions/metadata/action.yml:8 might want for variables or flow control in our various workflows. We centralize it here so as [CONFIG] .github/actions/metadata/action.yml:9 to have a single point of truth. This workflow also handles checking out the correct Git reference [CONFIG] .github/actions/metadata/action.yml:10 depending on workflow trigger and tags. This workflow is used in both CE and Ent and thus needs [CONFIG] .github/actions/metadata/action.yml:26 value: ${{ steps.workflow-metadata.outputs.compute-build }}

Finding

Does the system implement access controls that restrict access to financial systems and data to authorized personnel, with appropriate authentication and authorization mechanisms, as required under SOX Section 404 internal controls?

Remediation

Remediation refined by Gemini review

Possible False Positives (7)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

SOX-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration and documentation files, none of which are application source code directly implementing financial data integrity controls, therefore not confirming SOX-001 as required by the rules.

Evidence

[CONFIG] .github/actions/set-up-go/action.yml:73 # These results are used to balance our Go test groups, without which we could have [CONFIG] .github/actions/set-up-go/action.yml:74 # painfully unbalanced Go test execution times. We have to ensure current caches for all [DOCS] .github/instructions/generic/code_comments.instructions.md:36 // Per PCI DSS compliance requirements, credit card data must be encrypted at rest [DOCS] .github/instructions/generic/ember_tests.instructions.md:39 - Error handling and validation logic [DOCS] .github/instructions/generic/ember_tests.instructions.md:180 module('input validation', function (hooks) { [DOCS] .github/instructions/generic/ember_tests.instructions.md:197 test('it displays validation error when secret name is empty', async function (assert) { [DOCS] .github/instructions/generic/ember_tests.instructions.md:204 'Should display validation error for empty secret name' [DOCS] .github/instructions/generic/golang.instructions.md:52 - Use switch statements instead of repeated if statements for validation:

Finding

Does the system implement controls to ensure the integrity, accuracy, and completeness of financial data and transactions, consistent with SOX Section 302 requirements for management certification of financial statements?

Remediation

Review of the application source code, not just .github/actions/set-up-go/action.yml or .github/instructions/*.md, is required to identify specific control gaps for SOX-001. If financial data is processed, develop and integrate automated validation rules directly into relevant Go or Ember application code to comply with SOX Section 302 requirements.

SOX-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited, consisting solely of configuration files (.github/actions/checkout/action.yml) and documentation files (.github/instructions/generic/ember_general.instructions.md), pertains to code version control history and changelog guidelines, which do not directly demonstrate the presence or absence of tamper-evident audit trails for financial transactions within the application's runtime as required by SOX Section 802.

Evidence

[CONFIG] .github/actions/checkout/action.yml:47 # the most shallow clone possible for speed, but we also need to support getting history [CONFIG] .github/actions/checkout/action.yml:50 # history because we need all commits on the branch. [DOCS] .github/instructions/generic/ember_general.instructions.md:50 # Changelog Guidelines [DOCS] .github/instructions/generic/ember_general.instructions.md:52 For files in the `changelog/` directory: [DOCS] .github/instructions/generic/ember_general.instructions.md:58 // Changelog entries [CONFIG] .github/workflows/build.yml:40 # * Skipping builds entirely if the commit or PR only modifies changelog or website documentatio [CONFIG] .github/workflows/changelog-checker.yml:1 # This workflow checks that there is either a 'pr/no-changelog' label applied to a PR [CONFIG] .github/workflows/changelog-checker.yml:2 # or there is a changelog/<pr number>.txt file associated with a PR for a changelog entry

Finding

Does the system maintain a complete and tamper-evident audit trail of all financial transactions, modifications, and access events, sufficient to support the audit requirements under SOX Section 802?

Remediation

To prevent misinterpretation regarding SOX Section 802 requirements for financial transaction audit trails, clarify within `.github/actions/checkout/action.yml` and `.github/instructions/generic/ember_general.instructions.md` that these mechanisms serve code versioning and release documentation, not application-level financial auditing.

SOX-004 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists exclusively of configuration files and build scripts, not application source code, which under the defined rules leads to a 'POSSIBLE FALSE POSITIVE' verdict for SOX change management controls.

Evidence

[CONFIG] .build/entrypoint.sh:49 cd build || exit 1 [CONFIG] .build/go.sh:8 curl -L "https://go.dev/dl/go${GO_VERSION}.linux-${host_arch}.tar.gz" | tar -C /opt -zxv [CONFIG] .copywrite.hcl:1 schema_version = 1 [CONFIG] .copywrite.hcl:16 "enos/modules/k8s_deploy_vault/raft-config.hcl", [CONFIG] .github/CODEOWNERS:60 # Release config; service account is required for automation tooling. [CONFIG] .github/CODEOWNERS:61 /.release/ @hashicorp/github-secure-vault-core @hashicorp/team-vault-quality [DOCS] .github/ISSUE_TEMPLATE.md:15  [DOCS] .github/ISSUE_TEMPLATE.md:17 * Vault Version:

Finding

Does the system implement change management controls for software that processes financial data, including version control, code review, testing, and controlled deployment, consistent with SOX IT general controls?

Remediation

Update version control system settings to ensure that changes to `.github/CODEOWNERS`, `.build/entrypoint.sh`, and `.copywrite.hcl` always trigger mandatory code reviews and require explicit approval before merging. This action is essential for demonstrating robust change management controls over financial software components, as required by SOX IT general controls.

SOX-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cites a configuration file (`.github/CODEOWNERS`) pointing to general website content paths owned by an 'education' group, which is unlikely to be classified as a 'financial system' or 'financial transaction' component under SOX-005.

Evidence

[CONFIG] .github/CODEOWNERS:42 /website/data/ @hashicorp/vault-education-approvers [CONFIG] .github/CODEOWNERS:43 /website/public/ @hashicorp/vault-education-approvers [CONFIG] .github/CODEOWNERS:44 /website/content/ @hashicorp/vault-education-approvers [CONFIG] .github/CODEOWNERS:45 /website/templates/ @hashicorp/vault-education-approvers [CONFIG] .github/CODEOWNERS:46 /website/redirects.js @hashicorp/vault-education-approvers [CONFIG] .github/CODEOWNERS:49 /website/content/docs/plugins/ @hashicorp/vault-ecosystem @hashicorp/vault-education-ap [CONFIG] .github/CODEOWNERS:50 /website/content/docs/upgrading/plugins.mdx @hashicorp/vault-ecosystem @hashicorp/vault-education-ap [CONFIG] .github/CODEOWNERS:76 /website/content/docs/secrets/pki/ @hashicorp/vault-crypto @hashicorp/vault-educat

Finding

Does the system implement segregation of duties controls that prevent any single individual from having the ability to both authorize and execute financial transactions, or to both develop and deploy changes to financial systems?

Remediation

Review `.github/CODEOWNERS` lines 42-46 to confirm if `/website/data/`, `/website/public/`, `/website/content/`, `/website/templates/`, or `/website/redirects.js` directly impact financial systems or reporting. If so, reassign ownership from `@hashicorp/vault-education-approvers` to ensure proper segregation of duties, preventing SOX control deficiencies.

SOX-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively relates to build configuration and scripts for archiving the software's build artifacts, not to the system's policies or mechanisms for retaining financial records, audit work papers, or supporting documentation as required by SOX Section 802.

Evidence

[CONFIG] .github/actions/build-vault/action.yml:75 enableCrossOsArchive: true [CONFIG] .github/actions/set-up-go/action.yml:68 enableCrossOsArchive: true [CONFIG] .github/scripts/install-cob.sh:107 # adjust archive name based on OS [CONFIG] .github/scripts/install-cob.sh:123 # adjust archive name based on ARCH [CONFIG] .github/scripts/install-cob.sh:265 log_err "untar unknown archive format for ${tarball}" [CONFIG] .github/workflows/build.yml:308 enableCrossOsArchive: true [CONFIG] .github/workflows/copywrite.yml:24 archive-checksum: c299f830e6eef7e126a3c6ef99ac6f43a3c132d830c769e0d36fa347fa1af254 [CONFIG] .github/workflows/mend-pr-scan.yml:42 retention-days: 90

Finding

Does the system implement data retention policies that preserve financial records, audit work papers, and supporting documentation for the minimum retention period required under SOX Section 802 (not less than 7 years)?

Remediation

The `enableCrossOsArchive` settings in `.github/actions/build-vault/action.yml` and `.github/actions/set-up-go/action.yml`, along with archive handling in `.github/scripts/install-cob.sh`, pertain to the packaging and storage of application build artifacts. No modifications to these files are required to meet SOX Section 802 data retention obligations, as this evidence does not relate to financial records or audit documentation.

SOX-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration and documentation files, which do not directly demonstrate the presence or absence of formal SOX Section 404(a) internal control documentation, making the finding's confirmation based on this evidence a possible false positive per the defined rules.

Evidence

[CONFIG] .gitattributes:2 website/* linguist-documentation [CONFIG] .github/actions/metadata/action.yml:8 might want for variables or flow control in our various workflows. We centralize it here so as [DOCS] .github/instructions/generic/code_comments.instructions.md:36 // Per PCI DSS compliance requirements, credit card data must be encrypted at rest [DOCS] .github/instructions/generic/code_comments.instructions.md:166 - Use JSDoc for public API documentation [DOCS] .github/instructions/generic/ember_general.instructions.md:59 "ui (enterprise): Add advanced policy filtering" // enterprise features [DOCS] .github/instructions/generic/ember_general.instructions.md:8 This document provides general coding standards and project context for HashiCorp Ember.js UI applic [DOCS] .github/instructions/generic/ember_general.instructions.md:29 ## Framework and Tools [DOCS] .github/instructions/generic/ember_general.instructions.md:30 - **Frontend Framework**: Ember.js 4.x with Ember Octane patterns and decorators

Finding

Does the system provide evidence of documented internal controls over financial reporting, including control objectives, control activities, and monitoring procedures, as required under SOX Section 404(a)?

Remediation

Update `.github/instructions/generic/code_comments.instructions.md` to either explicitly document internal controls over financial reporting or provide clear references to where formal SOX Section 404(a) documentation is maintained, preventing non-compliance with SOX financial reporting requirements.

SOX-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided, `.github/CODEOWNERS`, defines code ownership and review policies, which are organizational controls over code changes, but do not directly implement the specific technical anti-tampering mechanisms (e.g., cryptographic integrity verification, immutable storage, or tamper detection for financial records) required by SOX Section 802.

Evidence

[CONFIG] .github/CODEOWNERS:7 * @hashicorp/vault [CONFIG] .github/CODEOWNERS:10 /builtin/credential/aws/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:11 /builtin/credential/github/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:12 /builtin/credential/ldap/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:13 /builtin/credential/okta/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:16 /builtin/logical/aws/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:17 /builtin/logical/cassandra/ @hashicorp/vault-ecosystem [CONFIG] .github/CODEOWNERS:18 /builtin/logical/consul/ @hashicorp/vault-ecosystem

Finding

Does the system implement controls to prevent unauthorized alteration or destruction of financial records, including integrity verification, immutable storage, and tamper detection mechanisms, consistent with SOX Section 802 anti-destruction requirements?

Remediation

The `.github/CODEOWNERS` file outlines critical code review policies; however, it does not implement the direct technical anti-tampering mechanisms like cryptographic integrity verification or immutable storage for financial records as required by SOX Section 802. Therefore, while strengthening this file with stricter multi-person review rules for financial data processing paths can reduce unauthorized code alterations, additional technical controls are necessary for full SOX-008 compliance.

TCPA

FCC · $500-$1,500 per violation

8 findings · 8 possible FP

Possible False Positives (8)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

TCPA-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The cited evidence, which refers to software license agreements in configuration and documentation files, is entirely unrelated to obtaining prior express written consent for marketing or promotional SMS messages, the core subject of this TCPA finding.

Evidence

[CONFIG] .release/linux/postinst:44 Agreement [CONFIG] .release/linux/postinst:47 agreement governing your use of the software made available here: [CONFIG] .release/linux/postinst:52 Agreement, the IBM International License Agreement for Evaluation of Programs [CONFIG] .release/linux/postinst:53 (for evaluation uses), or the IBM International License Agreement for Early [DOCS] CONTRIBUTING.md:142 ## Contributor License Agreement [DOCS] CONTRIBUTING.md:144 We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept [CONFIG] api/LICENSE:220 You alone, and You hereby agree to indemnify every Contributor for any [CONFIG] api/LICENSE:262 license agreements (excluding distributors and resellers) which have been

Finding

Does the system obtain prior express written consent before sending marketing or promotional text messages, including a clear and conspicuous disclosure that consent is being sought, as required under 47 U.S.C. §227(b)(1) and 47 CFR §64.1200(a)(2)?

Remediation

The files `.release/linux/postinst` and `CONTRIBUTING.md`, containing references to software license agreements, are irrelevant to TCPA SMS consent requirements and thus require no modification for this specific risk. If the system does send marketing SMS, ensure a robust consent mechanism is implemented elsewhere to avoid violations of 47 U.S.C. §227(b)(1).

TCPA-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided, which discusses internal system cancellation mechanisms and CI/CD job statuses, has no direct relevance to user-facing opt-out mechanisms required by TCPA for external communications.

Evidence

[DOCS] .github/instructions/generic/ember_js.instructions.md:84 - Only use `@task` from ember-concurrency when you need specific features like cancellation or `task [DOCS] .github/instructions/generic/golang.instructions.md:130 - Use context for cancellation and timeouts [CONFIG] .github/scripts/report-build-status.sh:23 # Sometimes failed jobs can have a result of "cancelled". Handle both. [CONFIG] .github/scripts/report-build-status.sh:26 if [[ "$job" == *"failure"* || "$job" == *"cancelled"* ]]; then [CONFIG] .github/workflows/actionlint.yml:8 # cancel existing runs of the same workflow on the same ref [CONFIG] .github/workflows/actionlint.yml:11 cancel-in-progress: true [CONFIG] .github/workflows/build-artifacts-ce.yml:245 if ! grep -q -v -E '(failure|cancelled)' <<< "$results"; then [CONFIG] .github/workflows/build.yml:71 cancel-in-progress: true

Finding

Does the system provide a clear and easy mechanism for recipients to opt out of receiving further messages, and does it honor opt-out requests promptly, as required under TCPA and CTIA guidelines?

Remediation

No modification to `.github/instructions/generic/ember_js.instructions.md`, `.github/instructions/generic/golang.instructions.md`, `.github/scripts/report-build-status.sh`, or `.github/workflows/actionlint.yml` is required, as the evidence refers to internal system cancellation logic, not user-facing opt-out mechanisms for TCPA compliance.

TCPA-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence exclusively references configuration files related to the build and containerization process of the Vault application, with no indication of functionality for outbound calls or messaging that would necessitate TCPA Do Not Call list checks.

Evidence

[CONFIG] .github/actions/build-vault/action.yml:138 driver-opts: network=host # So we can run our own little registry [CONFIG] .github/actions/build-vault/action.yml:141 run: docker run -d -p 5000:5000 --restart always --name registry registry:2 [CONFIG] .github/actions/containerize/action.yml:7 Containerize vault binaries and annotate them with the correct registry tags. Artifacts will be [CONFIG] .github/actions/containerize/action.yml:22 description: Package the binary into a UBI container suitable for the Redhat Quay registry. [CONFIG] .release/release-metadata.hcl:4 url_docker_registry_dockerhub = "https://hub.docker.com/r/hashicorp/vault" [CONFIG] .release/release-metadata.hcl:5 url_docker_registry_ecr = "https://gallery.ecr.aws/hashicorp/vault" [CONFIG] Dockerfile:85 FROM registry.access.redhat.com/ubi10/ubi-minimal AS ubi [SOURCE] builtin/credential/okta/backend_test.go:93 RegistryName: "okta-auth",

Finding

Does the system check phone numbers against the National Do Not Call Registry and maintain an internal do-not-call list before initiating outbound calls or messages, as required under 47 CFR §64.1200(c)?

Remediation

The listed configuration files, such as `.github/actions/build-vault/action.yml` and `.release/release-metadata.hcl`, are related to container packaging and distribution of Vault, not outbound communication capabilities. Therefore, no integration with the National Do Not Call Registry is required under 47 CFR §64.1200(c) based on this evidence.

TCPA-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited, consisting solely of style guides and general programming instructions in `.md` documentation files, is entirely unrelated to message frequency disclosure, consent, or TCPA compliance.

Evidence

[DOCS] .github/instructions/generic/code_comments.instructions.md:158 - Start with a capital letter [DOCS] .github/instructions/generic/ember_hbs.instructions.md:74 - **USE SENTENCE CASE**: All HTML headings (`<h1>`, `<h2>`, `<h3>`, etc.) should use sentence case ( [DOCS] .github/instructions/generic/ember_hbs.instructions.md:75 - **NO TITLE CASE**: Avoid title case where every major word is capitalized [DOCS] .github/instructions/generic/golang.instructions.md:13 - Use MixedCaps or mixedCaps rather than underscores for multiword names [DOCS] .github/instructions/generic/golang.instructions.md:93 - Understand slice sharing and capacity [DOCS] .github/instructions/generic/golang.instructions.md:138 - Understand escape analysis and stack vs heap allocation [DOCS] .github/instructions/generic/golang.instructions.md:155 - Understand escape analysis and stack vs heap allocation [CONFIG] .github/workflows/test-ci-cleanup.yml:62 # we'll fail on actually actionable things in the quota steep afterwards.

Finding

Does the system disclose to consumers the expected frequency of messages before obtaining consent, and does it enforce frequency limits consistent with the disclosed rate, as recommended by CTIA guidelines?

Remediation

No specific changes can be prescribed to documentation files such as `.github/instructions/generic/code_comments.instructions.md` or `.github/instructions/generic/ember_hbs.instructions.md` as their content focuses on code style and naming conventions rather than message frequency disclosure mechanisms, which are essential for TCPA compliance.

TCPA-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The primary analysis misinterpreted the use of the word 'brand' in the evidence, as the cited files refer to new features or UI branding, not sender identification in outbound messages relevant to TCPA.

Evidence

[DOCS] CHANGELOG-v0.md:1121 * **Brand New CLI**: Vault has a brand new CLI interface that is significantly [DOCS] CHANGELOG-v0.md:1661 Only)**: A brand new MFA system built on top of Identity allows MFA [CONFIG] ui/app/components/auth/page.hbs:28 <div class="brand-icon-large"> [CONFIG] ui/app/components/mfa/splash-card.hbs:12 <div class="brand-icon-large"> [SOURCE] ui/app/services/path-help.js:139 // if we have a brand new model [DOCS] ui/app/styles/components/icon.scss:83 .brand-icon-large { [CONFIG] ui/app/templates/vault/error.hbs:8 <Icon @name="vault" @size="24" class="brand-icon-large" /> [SOURCE] ui/tests/unit/unload-test.js:63 editRecord.name = 'Rebrand';

Finding

Does the system include proper sender identification in all outbound messages, including the identity of the entity sending the message and how to contact them, consistent with TCPA and CTIA requirements?

Remediation

The cited files (CHANGELOG-v0.md, ui/app/components/auth/page.hbs, ui/app/components/mfa/splash-card.hbs, ui/app/services/path-help.js) do not contain information related to outbound messages or sender identification; thus, no specific remediation can be proposed for TCPA-005 based on this evidence, indicating a false positive.

TCPA-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cites Terraform configuration files (`.tf`) related to verifying an internal LDAP audit trail, which is unrelated to the record-keeping of external consumer consent required by TCPA.

Evidence

[CONFIG] enos/modules/verify_secrets_engines/modules/read/ldap/ldap.tf:356 resource "enos_remote_exec" "ldap_verify_audit_trail" { [CONFIG] enos/modules/verify_secrets_engines/modules/read/ldap/ldap.tf:452 enos_remote_exec.ldap_verify_audit_trail

Finding

Does the system maintain records of consent that would be sufficient to demonstrate compliance in the event of a dispute, including the date, time, method of consent, and the specific consent language presented to the consumer?

Remediation

To meet TCPA record-keeping requirements, the `enos/modules/verify_secrets_engines/modules/read/ldap/ldap.tf` file must define resources that provision or integrate with a consent management system, capable of capturing and storing consumer consent records (date, time, method, language), or face high TCPA non-compliance fines.

TCPA-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively points to config files and documentation containing the word 'remove' in technical contexts (e.g., removing a character from a path, a post-removal script for a package, a TODO to remove old API), which is entirely unrelated to the legal concept of 'revocation of consumer consent' under TCPA.

Evidence

[CONFIG] .github/actions/build-vault/action.yml:242 postremove: .release/linux/postrm [DOCS] .github/instructions/generic/code_comments.instructions.md:185 // Remove leading # from ref path [DOCS] .github/instructions/generic/code_comments.instructions.md:193 const parts = ref.split('/').slice(1); // Remove leading # [DOCS] .github/instructions/generic/code_comments.instructions.md:196 // Remove leading # from ref path [DOCS] .github/instructions/generic/code_comments.instructions.md:238 // TODO: Remove this after migration to v2 API (added 2019) [DOCS] .github/instructions/generic/code_comments.instructions.md:247 - **Remove** comments that add no value [DOCS] .github/instructions/generic/ember_hbs.instructions.md:15 - Remove unnecessary quotes around dynamic component arguments [DOCS] .github/instructions/generic/ember_hbs.instructions.md:21 - Remove quotes around dynamic data attributes: `data-test-id={{value}}` not `data-test-id="{{value}

Finding

Does the system honor revocation of consent through any reasonable means indicated by the consumer, not limited to specific keywords, and process revocation within a reasonable timeframe, consistent with FCC guidance?

Remediation

The lines identified in `.github/actions/build-vault/action.yml` (line 242) and `.github/instructions/generic/code_comments.instructions.md` (lines 185, 193, 196, 238) refer to technical code removal operations or build processes, not consumer consent revocation. No specific code changes are required in these files to comply with TCPA-007, as the evidence does not indicate a regulatory risk.

TCPA-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files and documentation, not application source code that would demonstrate the presence or absence of TCPA time-of-day enforcement for outbound communications.

Evidence

[CONFIG] .github/dependabot.yml:6 schedule: [DOCS] .github/instructions/generic/ember_js.instructions.md:90 - **WARNING**: Avoid `new Date()` as it uses the browser's timezone [DOCS] .github/instructions/generic/ember_js.instructions.md:91 - Use `Date.UTC()` constructor instead of `new Date()` for consistent timezone handling [CONFIG] .github/workflows/build.yml:13 # * That the workflow must work under when triggered by pull_request, push, schedule, and [CONFIG] .github/workflows/build.yml:32 # under normal pull_request, push, schedule, and workflow_dispatch trigger events. [CONFIG] .github/workflows/build.yml:47 # * The ability to build all of our artifacts on a scheduled cadence to ensure we don't [CONFIG] .github/workflows/build.yml:66 schedule: [CONFIG] .github/workflows/build.yml:81 # * The workflow was triggered by on schedule to test building all artifacts.

Finding

Does the system enforce time-of-day restrictions for outbound calls and messages, ensuring they are not sent before 8:00 AM or after 9:00 PM in the recipient's local time zone, as required under 47 CFR §64.1200(c)(1)?

Remediation

The guidance in `.github/instructions/generic/ember_js.instructions.md` to use `Date.UTC()` for consistent timezone handling should be applied to any outbound messaging logic within the Ember.js application. Verify that any such logic correctly calculates the recipient's local time and restricts messages to between 8:00 AM and 9:00 PM, to avoid violations of 47 CFR §64.1200(c)(1).

What This Analysis Covers

OpenDocket scans source code patterns — specifically whether code handles regulated data in compliance-aware ways. It searches for evidence of encryption, access controls, consent mechanisms, audit logging, and other patterns that regulators look for.

What It Does Not Cover

Only public repository content is analyzed
Files in .gitignore are not scanned
Infrastructure, deployment, and cloud configuration are outside scope
Operational policies and procedures are outside scope
This analysis covers code at time of scan — changes after scan date are not reflected

Legal Limitations

This report is not defensible in court
It does not constitute legal advice
It does not satisfy regulatory audit requirements
To obtain a defensible compliance assessment, engage a licensed compliance attorney and certified auditor
OpenDocket provides directional guidance only

How Findings Are Generated

Primary analysis by Claude Sonnet (Anthropic)
Verification by Gemini 2.5 Flash (Google)
Question libraries are open source and community-maintained
All questions cite regulatory source text
Questions have not been validated by a licensed attorney

Why Two Models?

Claude Sonnet scans broadly — it finds every pattern that could indicate a compliance risk. This produces a comprehensive set of findings but includes noise from documentation files, config references, and test data.

Gemini 2.5 Flash then challenges each finding independently. It asks: is this evidence from actual application code? Would a regulator actually find this concerning? Is the severity appropriate?

The result is a tiered output:

CONFIRMED — Gemini agrees this is a real risk
CONTEXT DEPENDENT — Risk depends on deployment/infrastructure
POSSIBLE FALSE POSITIVE — Likely noise, review before acting

The confirmed count is the number you should act on. The total count shows the full scope of what was examined.

Evidence Tiers

Evidence is classified into three tiers based on file type:

[SOURCE] — Application source code (.ts, .py, .go, .rs, etc.) — strongest evidence
[CONFIG] — Configuration files (.yml, .json, .toml, Dockerfile) — moderate evidence
[DOCS] — Documentation (.md, .txt, .html) — context only, cannot produce High Risk findings

A finding is only classified as High Risk if supported by at least two source code files with matching evidence. Documentation references alone produce Pattern of Concern at most.

How to Use This Report

Share with your engineering lead for remediation planning
Share with your attorney as a starting point for compliance review
Re-scan after remediation to track progress
Do not present this as proof of compliance

Findings based on OpenDocket's open source question libraries. View and contribute