Upstream Pins

Picket compatibility work is pinned to upstream reference snapshots. Upgrade these pins deliberately and update oracle fixtures in the same change.

Do not commit machine-specific clone paths. Developers can keep reference repositories anywhere and point Picket tooling at them with environment variables. When an environment variable is not set, local scripts try a sibling clone next to this repository.

Reference Clone Discovery

Project	Environment variable	Default sibling clone	Role
Gitleaks	PICKET_GITLEAKS_REPO	../gitleaks	Primary compatibility oracle
Scout	PICKET_SCOUT_REPO	../scout	Regex, globbing, ignore, and Native AOT behavior reference
TruffleHog	PICKET_TRUFFLEHOG_REPO	../trufflehog	Verification, sources, and analyze reference
Nosey Parker	PICKET_NOSEYPARKER_REPO	../noseyparker	Historical datastore/rule-QA/performance reference
Kingfisher	PICKET_KINGFISHER_REPO	../kingfisher	Validation breadth, revocation, access-map, and reporting reference
.NET Runtime	PICKET_DOTNET_RUNTIME_REPO	../runtime	Native AOT/runtime implementation reference

Current Pins

Project	Version	Commit	Remote
Gitleaks	v8.30.0-23-g4c232b5	4c232b5014f7618360bd992b4c489cb055881c6b	https://github.com/gitleaks/gitleaks.git
Scout	v0.4.7	22104874ba364214bc46b2ce61dd4d2f19a88ce2	https://github.com/willibrandon/scout.git
TruffleHog	v3.95.8-1-gf2cd191b9	f2cd191b97098913a07522227d2b5e40e57252f4	https://github.com/trufflesecurity/trufflehog.git
Nosey Parker	v0.24.0-31-g2e6e7f36	2e6e7f36ce36619852532bbe698d8cb7a26d2da7	https://github.com/praetorian-inc/noseyparker.git
Kingfisher	v1.105.0	78904df5ea7354a7dc3700e3c41a124524d23083	https://github.com/mongodb/kingfisher.git
.NET Runtime	fe5e47348f8	fe5e47348f86013bbe8f3041e56f5208cd632e53	https://github.com/dotnet/runtime

Refresh the table from local clones with:

dotnet run --file ./scripts/Capture-UpstreamPins.cs -- -Update

Print the captured table without editing docs with:

dotnet run --file ./scripts/Capture-UpstreamPins.cs --

File-Based Utility Apps

The oracle utilities under scripts/ are .NET file-based apps. They are kept outside project directories and have a local scripts/Directory.Build.props so utility settings are isolated from package metadata used by shipped projects.

Run one-off commands with dotnet run --file and put script arguments after --:

dotnet run --file ./scripts/Capture-UpstreamPins.cs -- -AllowMissing

For CI, repeated runs, or parallel work, build first and run without rebuilding:

dotnet build ./scripts/Capture-UpstreamPins.cs --nologo --verbosity quiet
dotnet run --file ./scripts/Capture-UpstreamPins.cs --no-build -- -AllowMissing

If the SDK cache gets stale or contested, use dotnet clean file-based-apps. To force one app to rebuild, use dotnet clean ./scripts/<app>.cs followed by dotnet build ./scripts/<app>.cs.

Repository convention tests build every executable utility app and run fake-input coverage for the GitHub hosted-alert capture and comparison utilities.

The executable utility files use the documented Unix shebang form #!/usr/bin/env -S dotnet --, and repository line endings are LF through .gitattributes. On Unix-like systems, direct execution passes arguments without an extra separator:

./scripts/Capture-UpstreamPins.cs -AllowMissing

Microsoft .NET and CLI Guidance

Runtime, testing, and command-line behavior are based on Microsoft Learn documentation reviewed on 2026-07-07:

• System.CommandLine overview: https://learn.microsoft.com/en-us/dotnet/standard/commandline/
• System.CommandLine syntax overview: https://learn.microsoft.com/en-us/dotnet/standard/commandline/syntax
• System.CommandLine parse and invoke guidance: https://learn.microsoft.com/en-us/dotnet/standard/commandline/how-to-parse-and-invoke
• System.CommandLine parsing and validation guidance: https://learn.microsoft.com/en-us/dotnet/standard/commandline/how-to-customize-parsing-and-validation
• System.CommandLine parser configuration guidance: https://learn.microsoft.com/en-us/dotnet/standard/commandline/how-to-configure-the-parser
• System.CommandLine help customization guidance: https://learn.microsoft.com/en-us/dotnet/standard/commandline/how-to-customize-help
• System.CommandLine tab completion guidance: https://learn.microsoft.com/en-us/dotnet/standard/commandline/how-to-enable-tab-completion
• System.CommandLine command-line design guidance: https://learn.microsoft.com/en-us/dotnet/standard/commandline/design-guidance
• System.CommandLine 2.0.0-beta5+ migration guide: https://learn.microsoft.com/en-us/dotnet/standard/commandline/migration-guide-2.0.0-beta5

Gitleaks Compatibility

The embedded strict-compatibility default config in src/Picket.Compat/EmbeddedGitleaksConfig.cs is generated from:

<gitleaks clone>/config/gitleaks.toml

Resolve <gitleaks clone> with PICKET_GITLEAKS_REPO or the sibling ../gitleaks fallback.

Current Gitleaks code defaults are treated as authoritative when README text and implementation disagree. For example, --max-decode-depth follows the pinned code default of 5.

Expected oracle command shapes:

gitleaks git <repo> --config <config> --report-format json --report-path <out>
gitleaks dir <path> --config <config> --report-format json --report-path <out>
gitleaks stdin --config <config> --report-format json --report-path <out>

Capture pinned Gitleaks oracle outputs with:

dotnet run --file ./scripts/Capture-GitleaksOracle.cs -- -Mode dir -Source <fixture-path> -Config <config> -ReportFormat json,sarif
dotnet run --file ./scripts/Capture-GitleaksOracle.cs -- -Mode git -Source <repo> -Config <config> -ReportFormat json
dotnet run --file ./scripts/Capture-GitleaksOracle.cs -- -Mode stdin -StdinPath <input-file> -Config <config> -ReportFormat json

For directory fixtures where report paths must stay relative, run from an explicit fixture working directory and pass the same relative command arguments that Gitleaks should see:

dotnet run --file ./scripts/Capture-GitleaksOracle.cs -- -Mode dir -WorkingDirectory <fixture-root> -Source . -Config .gitleaks.toml -ReportFormat json

The script resolves the executable from -GitleaksPath, PICKET_GITLEAKS_BIN, or gitleaks on PATH. It resolves the pinned clone from PICKET_GITLEAKS_REPO or ../gitleaks, then writes reports, stdout, stderr, and metadata.json under artifacts/oracles/gitleaks by default.

Oracle reports can contain raw secrets from fixtures. Keep generated artifacts out of source control unless a follow-up normalization step has redacted and reviewed them for use as committed golden files.

Capture a side-by-side Gitleaks/Picket compatibility bundle with:

dotnet run --file ./scripts/Capture-CompatibilityOracle.cs -- -Mode dir -Source <fixture-path> -Config <config> -ReportFormat json,sarif
dotnet run --file ./scripts/Capture-CompatibilityOracle.cs -- -Mode dir -WorkingDirectory <fixture-root> -Source . -Config .gitleaks.toml -ReportFormat json

The wrapper writes gitleaks/, picket/, and comparison.json under artifacts/oracles/compatibility by default. Set PICKET_BIN or pass -PicketPath when the Release picket executable has not already been built in the repository output layout used by the test suite.

Promote a reviewed compatibility bundle into source-controlled golden fixtures with:

dotnet run --file ./scripts/Promote-CompatibilityOracle.cs -- -Name <case-name> -RedactionMapPath <redactions.json>

The promotion step writes normalized files under tests/fixtures/oracles and a manifest.json with upstream pin metadata, file hashes, and comparison results. It strips known local paths, normalizes line endings, applies the redaction map, normalizes volatile Gitleaks stderr timestamps and scan durations, and fails if promoted files still contain drive-root paths or any redaction-map secret. -AllowUnredacted is only for synthetic no-secret captures.

Picket compatibility tests should compare normalized reports, fingerprints, config diagnostics, exit codes, and stderr text against this pinned version.

Gitleaks Issue Review

The native rule and matching backlog was reviewed against open Gitleaks issues on 2026-07-19. These responses affect picket-default or native matching only; the pinned strict compatibility rules and behavior remain unchanged.

Issue	Native Picket response
#2158	Anthropic OAuth access and refresh token rules with offline shape validation.
#2104	Anthropic OAuth coverage plus a structured MCP detector scoped to mcpServers.<server>.env; environment references and ordinary settings are rejected.
#2094	Claude Code remote-session URL rule with host, path, and identifier validation.
#2180	Groq and xAI API key rules with offline shape validation.
#2192	GitHub App tokens support both classic and stateless installation formats in detection, validation, live verification, and explicit revocation.
#1942	Google API keys accept URL query delimiters such as & without consuming the delimiter.
#1933	A bounded YAML detector identifies kind: Secret regardless of mapping order and scopes values to that resource.
#2093	The Square rule uses a reviewed native randomness threshold to suppress encoded structured text.
#1762	The native generic API-key rule includes the reported Vue attribute false-positive regression.
#1772	The native generic API-key rule accepts long assignment spacing.
#1773	The native generic API-key rule recognizes the additional credential-name forms from the issue corpus.
#1785	The native generic API-key rule covers Python annotations, SecretStr, continuations, and parenthesized assignments.
#1818	Structured GCP service-account detection reports the private key once and has an overlapping-rule regression test.
#2121, #2160	One Scout FindCaptures result supplies each regex match and its capture spans; Picket does not run a second regex search to extract the secret.

Primary format and provider references reviewed for this work:

• Anthropic Claude Code authentication: https://code.claude.com/docs/en/authentication
• OpenAI API authentication: https://platform.openai.com/docs/api-reference/authentication
• OpenAI Codex authentication: https://developers.openai.com/codex/auth
• Model Context Protocol local-server configuration: https://modelcontextprotocol.io/docs/develop/connect-local-servers
• Model Context Protocol debugging and env configuration: https://modelcontextprotocol.io/docs/tools/debugging
• Docker login configuration: https://docs.docker.com/reference/cli/docker/login/
• JSON Web Key specification: https://www.rfc-editor.org/rfc/rfc7517
• Kubernetes Secrets: https://kubernetes.io/docs/concepts/configuration/secret/
• npmrc configuration: https://docs.npmjs.com/cli/v11/configuring-npm/npmrc
• SARIF 2.1.0 columnKind: https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#def_columnKind

Provider Revocation References

Native analysis and direct revocation behavior are based on provider documentation reviewed on 2026-07-13:

• GitHub credential revocation API: https://docs.github.com/en/rest/credentials/revoke
• GitHub token expiration and revocation: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation
• AWS IAM update-access-key: https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html
• AWS IAM delete-access-key: https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html
• AWS IAM access-key rotation workflow: https://docs.aws.amazon.com/IAM/latest/UserGuide/id-credentials-access-keys-update.html
• Azure Storage account key renewal: https://learn.microsoft.com/en-us/cli/azure/storage/account/keys
• GCP API key delete command: https://docs.cloud.google.com/sdk/gcloud/reference/services/api-keys/delete
• GCP service-account key delete command: https://docs.cloud.google.com/sdk/gcloud/reference/iam/service-accounts/keys/delete

GitHub Source References

Native GitHub repository, pull request, issue, issue comment, release, release asset, Actions artifact, gist, gist comment, organization, and user source enumeration is based on GitHub REST API documentation reviewed on 2026-07-07:

• GitHub repository metadata REST API: https://docs.github.com/rest/repos/repos
• GitHub pull requests REST API: https://docs.github.com/rest/pulls/pulls
• GitHub issues REST API: https://docs.github.com/rest/issues/issues
• GitHub issue comments REST API: https://docs.github.com/rest/issues/comments
• GitHub releases REST API: https://docs.github.com/rest/releases/releases
• GitHub release assets REST API: https://docs.github.com/rest/releases/assets
• GitHub Actions artifacts REST API: https://docs.github.com/rest/actions/artifacts
• GitHub gists REST API: https://docs.github.com/rest/gists/gists
• GitHub gist comments REST API: https://docs.github.com/rest/gists/comments
• GitHub REST pagination: https://docs.github.com/en/rest/using-the-rest-api/using-pagination-in-the-rest-api
• Git trees REST API: https://docs.github.com/v3/git/trees
• Repository contents REST API: https://docs.github.com/en/rest/repos/contents

GitLab Source References

Native GitLab group project, project repository, merge request source, project snippet, pipeline job, job trace, job artifact, and generic package file enumeration is based on GitLab REST API documentation reviewed on 2026-07-09:

• GitLab repositories API: https://docs.gitlab.com/api/repositories/
• GitLab groups API: https://docs.gitlab.com/api/groups/
• GitLab merge requests API: https://docs.gitlab.com/api/merge_requests/
• GitLab pipelines API: https://docs.gitlab.com/api/pipelines/
• GitLab project snippets API: https://docs.gitlab.com/api/project_snippets/
• GitLab jobs API: https://docs.gitlab.com/api/jobs/
• GitLab job artifacts API: https://docs.gitlab.com/api/job_artifacts/
• GitLab packages API: https://docs.gitlab.com/api/packages/
• GitLab generic packages repository: https://docs.gitlab.com/user/packages/generic_packages/
• GitLab repository files API: https://docs.gitlab.com/api/repository_files/
• GitLab REST pagination: https://docs.gitlab.com/api/rest/#pagination

Gitea Source References

Native Gitea repository, Actions artifact, and generic package file source enumeration is based on Gitea API documentation reviewed on 2026-07-09:

• Gitea API documentation: https://docs.gitea.com/api/
• Gitea Actions artifact REST API: https://docs.gitea.com/api/next/
• Gitea generic package registry: https://docs.gitea.com/usage/packages/generic
• Gitea live swagger: https://gitea.com/swagger.v1.json

Picket uses Gitea organization and user repository-list endpoints with page and limit=100, repository metadata to resolve the default branch, branch metadata to resolve branch names to commit IDs when available, recursive git tree enumeration with per_page=1000, the raw repository file endpoint for selected file bytes, and pull request metadata to resolve source-head commits and source repositories. Issue scans use repository issue lists with type=issues and repository issue-comment lists, filtering comments back to selected issue numbers through issue_url. Release scans use repository release lists and release asset metadata; returned browser download URLs are fetched without forwarding the token, but must stay on the configured Gitea host or one of its subdomains. Actions artifact scans list repository artifacts through /repos/{owner}/{repo}/actions/artifacts, or run-scoped artifacts through /repos/{owner}/{repo}/actions/runs/{run}/artifacts, then download /repos/{owner}/{repo}/actions/artifacts/{artifact_id}/zip as application/octet-stream. Redirected ZIP downloads are fetched without forwarding the token and are still subject to endpoint-guard checks. Generic package scans use /packages/{owner} with type=generic, page, and limit=100, list files through /packages/{owner}/generic/{package_name}/{package_version}/files, then use the documented /api/packages/{owner}/generic/{package_name}/{package_version}/{file_name} download route for selected files. Tokens are read from environment variables, sent as an Authorization: token ... header, and are not logged.

Bitbucket Source References

Native Bitbucket Cloud repository source enumeration is based on Atlassian Bitbucket Cloud REST API documentation reviewed on 2026-07-09:

• Bitbucket Cloud REST API: https://developer.atlassian.com/cloud/bitbucket/rest/
• Bitbucket source API: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-source/
• Bitbucket repository API: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-repositories/
• Bitbucket projects API: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-projects/
• Bitbucket pull requests API: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pullrequests/
• Bitbucket downloads API: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-downloads/
• Bitbucket pipelines API: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pipelines/
• Bitbucket snippets API: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-snippets/

Picket uses Bitbucket repository metadata to resolve the main branch, paged workspace repository listings and source directory listings with pagelen=100, project metadata plus repository project.key filtering for project-scoped workspace scans, explicit directory walking instead of the max_depth parameter, raw source file responses for selected file bytes, pull request metadata to resolve source-head commits and source repositories, workspace snippet listings plus snippet metadata to enumerate snippet files, raw snippet file endpoints for snippet bytes, repository download listings plus Bitbucket’s documented download-artifact redirect endpoint for artifact bytes, and pipeline step listings plus step log endpoints for selected pipeline logs. Bearer tokens and app passwords are read from environment variables, are not logged, and are not forwarded to redirected artifact or pipeline-log URLs. Snippet raw-file redirects are followed only when they stay on the configured Bitbucket API endpoint because those redirected API requests still require the Bitbucket credential.

Native Bitbucket Data Center repository enumeration is based on Atlassian REST API and access-token documentation reviewed on 2026-07-10:

• Bitbucket Data Center REST introduction: https://developer.atlassian.com/server/bitbucket/rest/v1000/intro/
• Bitbucket Data Center repository API: https://developer.atlassian.com/server/bitbucket/rest/v1000/api-group-repository/
• Bitbucket Data Center pull requests API: https://developer.atlassian.com/server/bitbucket/rest/v1000/api-group-pull-requests/
• Bitbucket Data Center personal access tokens: https://confluence.atlassian.com/bitbucketserver/managing-personal-access-tokens-1005339986.html

Picket requires an explicit Data Center REST API base path, lists project repositories and repository files with limit=100, and follows the server’s nextPageStart cursor. It resolves default branches, named refs, and pull request source heads to immutable commit IDs before downloading raw files. Bearer and Basic credentials are read from environment variables and are sent only as request headers. Redirects are disabled.

Azure DevOps Source References

Native Azure DevOps repository, wiki, build artifact, build log, release artifact, and Azure Artifacts NuGet package source enumeration is based on Microsoft Learn REST API documentation reviewed on 2026-07-09:

• Azure DevOps repositories list REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/git/repositories/list?view=azure-devops-rest-7.1
• Azure DevOps Git items list REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/git/items/list?view=azure-devops-rest-7.1
• Azure DevOps wikis list REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/wiki/wikis/list?view=azure-devops-rest-7.1
• Azure DevOps build artifacts list REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/build/artifacts/list?view=azure-devops-rest-7.1
• Azure DevOps build artifact file REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/build/artifacts/get-file?view=azure-devops-rest-7.1
• Azure DevOps build logs list REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/get-build-logs?view=azure-devops-rest-7.1
• Azure DevOps build log REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/get-build-log?view=azure-devops-rest-7.1
• Azure DevOps release get REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/release/releases/get-release?view=azure-devops-rest-7.1
• Azure Artifacts feeds REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/artifacts/feed-management/get-feeds?view=azure-devops-rest-7.1
• Azure Artifacts packages REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/artifacts/artifact-details/get-packages?view=azure-devops-rest-7.1
• Azure Artifacts NuGet download REST API: https://learn.microsoft.com/en-us/rest/api/azure/devops/artifactspackagetypes/nuget/download-package?view=azure-devops-rest-7.1
• Azure Artifacts Universal Packages download guidance: https://learn.microsoft.com/en-us/azure/devops/artifacts/quickstarts/download-universal-packages?view=azure-devops

Azure Blob Source References

Native Azure Blob Storage container source enumeration is based on Microsoft Learn REST API documentation reviewed on 2026-07-08:

• Azure Blob Storage REST API: https://learn.microsoft.com/en-us/rest/api/storageservices/blob-service-rest-api
• List Blobs REST API: https://learn.microsoft.com/en-us/rest/api/storageservices/list-blobs
• Get Blob REST API: https://learn.microsoft.com/en-us/rest/api/storageservices/get-blob
• Azure Storage service versioning: https://learn.microsoft.com/en-us/rest/api/storageservices/versioning-for-the-azure-storage-services

Picket uses Azure Storage service version 2026-04-06 for Blob Storage REST requests because Microsoft documents it as the latest fully deployed service version as of the reviewed versioning page. The newer 2026-06-06 service version is broadly enabled but has documented tenant exceptions, so it is not used as the scanner default yet.

S3 Source References

Native S3 bucket source enumeration is based on AWS API documentation reviewed on 2026-07-08:

• Amazon S3 API Reference: https://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html
• Amazon S3 ListObjectsV2 API: https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html
• Amazon S3 GetObject API: https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html
• AWS SigV4 signed requests: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-create-signed-request.html

Picket uses S3 REST ListObjectsV2 with max-keys=1000 and NextContinuationToken pagination, and GetObject for object bytes. Requests are signed with SigV4 for service s3; the secret access key is used only for HMAC signing and is never written to logs, reports, or diagnostics.

GCS Source References

Native Google Cloud Storage bucket source enumeration is based on Google Cloud documentation reviewed on 2026-07-08:

• Google Cloud Storage JSON API overview: https://docs.cloud.google.com/storage/docs/json_api
• Google Cloud Storage objects.list API: https://docs.cloud.google.com/storage/docs/json_api/v1/objects/list
• Google Cloud Storage objects.get API: https://docs.cloud.google.com/storage/docs/json_api/v1/objects/get
• Google Cloud authentication token types: https://docs.cloud.google.com/docs/authentication/token-types

Picket uses the Cloud Storage JSON API objects.list method with maxResults=1000, projection=noAcl, optional prefix, optional userProject, and nextPageToken pagination. Object bytes are downloaded with objects.get and alt=media. OAuth bearer tokens are read from environment variables and are not logged.

Container Registry and Zstandard References

Native registry image enumeration is based on specifications and primary implementation guidance reviewed on 2026-07-09:

• OCI Distribution Specification 1.1.1: https://github.com/opencontainers/distribution-spec/blob/v1.1.1/spec.md
• OCI Image Specification 1.1.1 manifests: https://github.com/opencontainers/image-spec/blob/v1.1.1/manifest.md
• OCI Image Specification 1.1.1 image indexes: https://github.com/opencontainers/image-spec/blob/v1.1.1/image-index.md
• OCI Image Specification 1.1.1 layer media types: https://github.com/opencontainers/image-spec/blob/v1.1.1/media-types.md
• Docker Registry token authentication: https://docs.docker.com/reference/api/registry/auth/

Picket resolves exact tags or digests through manifest and blob endpoints. It does not enumerate catalogs or tags. Bearer challenges request repository pull scope, cross-origin blob redirects are credential-free, and SHA-256 descriptor digests are verified before content is scanned.

Zstandard decompression uses the stable upstream streaming C API through source-generated LibraryImport bindings. Normal Windows, glibc Linux, and macOS runtime assets come from the native asset set in ZstdNet 1.5.7, repository commit 04902458f73940a2163c330b4c412852ac53ade0; its managed wrapper is excluded. Musl releases build the decompression-only zstandard 1.5.7 shared library from the official release archive pinned to SHA-256 eb33e51f49a15e023950cd7825ca74a4a2b43db8354825ac24fc1b7ee09e6fa3. ZstdSharp.Port is test-only and generates independent compressed fixtures; it is not linked into shipped Picket binaries.

GitHub Secret Scanning Oracle

GitHub Secret Protection secret scanning is a hosted proprietary system, not a local Gitleaks binary. Use it as an alert oracle for repository parity, not as a source-code implementation reference. GitHub documents supported secret scanning patterns and alert scope in its public docs:

• https://docs.github.com/en/code-security/reference/secret-security/supported-secret-scanning-patterns
• https://docs.github.com/en/code-security/reference/secret-security/secret-scanning-scope
• https://docs.github.com/en/rest/secret-scanning/secret-scanning

Capture sanitized GitHub alert metadata with:

dotnet run --file ./scripts/Capture-GitHubSecretScanningOracle.cs -- -Repository owner/name -State open -IncludeLocations

The script uses gh api and writes artifacts/oracles/github-secret-scanning/alerts.json by default. The output contains alert numbers, states, secret types, URLs, summary counts, and optional location metadata. It intentionally does not write GitHub’s raw secret field.

Use this oracle to compare Picket native rule coverage against GitHub alert classes and locations. Keep Gitleaks compatibility oracles separate because GitHub and Gitleaks do not have identical allowlist semantics.

When the captured locations include commit SHAs, run a native git-history scan to JSONL before comparing:

picket git . --profile picket --report-format jsonl `
  --report-path artifacts/oracles/github-secret-scanning/picket-git.jsonl

For current-tree experiments, a native filesystem scan report can still be useful, but it is not evidence for hosted historical alert parity.

Compare the hosted-alert oracle with:

dotnet run --file ./scripts/Compare-GitHubSecretScanningOracle.cs -- `
  -OraclePath artifacts/oracles/github-secret-scanning/alerts.json `
  -PicketReportPath artifacts/oracles/github-secret-scanning/picket-git.jsonl `
  -OutputPath artifacts/oracles/github-secret-scanning/comparison.json

The comparison output records mapped alert classes, missing mapped locations, unexpected mapped findings, hosted alert types without a Picket mapping, and Picket rule IDs that are not part of the GitHub mapping. It matches by commit SHA when both sides have commit metadata and otherwise falls back to line-level path matching. It does not copy raw secret, match, or line fields from the Picket report.