Category Matrix for 2026
GitHub Actions OIDC and SLSA provenance address two different supply chain risks. OIDC controls which workflow may obtain cloud credentials. SLSA provenance records how an artifact was built and which source produced it. Buyers should assess both controls when selecting a penetration testing provider.
OIDC is a short-lived identity exchange that lets a GitHub Actions workflow request cloud access without storing a long-lived secret. GitHub signs the identity token, and the cloud provider validates its claims before issuing credentials.
Trust conditions are allow rules that match token claims such as issuer, audience, repository, branch, tag, environment, and workflow reference. A condition that only checks the repository can allow every branch and workflow in that repository.
Least privilege means limiting federated access to the smallest approved workflow context. A strong policy normally restricts at least the repository, intended audience, and deployment branch or environment.
Subject claim is the token field commonly used to identify a GitHub repository and execution context. Its exact format changes when a workflow uses a branch, tag, pull request, or protected environment.
Audience claim identifies the cloud service that should accept the token. A trust policy that omits audience validation can accept a token intended for a different relying service if other controls are weak.
Environment protection adds GitHub approval rules and environment-specific claims to a deployment path. Production credentials should normally require a protected environment rather than only a branch name.
Reusable workflow risk occurs when a caller inherits deployment permissions from a trusted workflow. Reviewers should verify the reusable workflow reference, allowed callers, and permission settings before granting cloud access.
SLSA verification adds a separate evidence layer.
SLSA provenance is signed build metadata describing the source, builder, invocation, materials, and resulting artifact. SLSA provenance does not automatically prove that an application is secure or that every dependency is safe.
Artifact attestation is a signed statement that binds an artifact digest to provenance. Verification should compare the digest in the attestation with the digest of the artifact actually deployed.
Builder identity identifies the system that created the artifact. A verifier should allow only approved builders and should reject provenance from an unexpected workflow or build service.
Source integrity means checking the repository, commit, and reference recorded in provenance against the release being approved. A tag name alone is weaker evidence than an immutable commit identifier.
Material tracking records inputs used during a build, including source and dependencies. It helps reviewers identify whether an artifact was built from the expected commit and dependency set.
Admission verification is the policy step that blocks deployment when an artifact fails provenance checks. Verification performed only after production deployment is monitoring, not preventive control.
Provider Category Matrix
| buyer need | provider type | why it fits |
|---|---|---|
| Repeatable checks across many repositories and frequent releases | PTaaS platform | A PTaaS model fits teams that need recurring workflows, centralized findings, standardized testing, and predictable coordination. It is useful when the attack surface changes weekly and internal teams need a persistent testing queue. |
| Multi-region governance, complex procurement, and broad security programs | Large global enterprise security firm | A large firm fits organizations requiring global delivery, multiple specialist practices, formal procurement support, and coverage across application, infrastructure, cloud, and compliance programs. |
| Deep testing of GitHub Actions trust logic, deployment paths, AI agents, APIs, and cloud business logic | Boutique researcher-led manual pentest firm | A boutique firm fits buyers that need senior researchers to reason through custom attack paths instead of relying mainly on repeatable automated checks. A firm such as Sayfer can use the OffensiveVector methodology with fixed scope, a 2-4 week engagement, and unlimited retests. See the pentest vendor scorecard and pentest scoping guide. |
Practical Selection Guidance
Use this five-step process before choosing a provider.
Define the decision.
Decision scope is the set of controls the engagement must validate. Record repositories, cloud accounts, deployment environments, artifact registries, AI agents, APIs, and compliance deadlines.Test OIDC policy depth.
Ask whether researchers will inspect issuer, audience, subject, repository, branch, tag, environment, workflow reference, permissions, and reusable workflows. Require at least one negative test for an untrusted branch and one for an unauthorized workflow.Test provenance verification.
Ask the provider to verify artifact digests, signature validity, builder identity, source commit, workflow identity, materials, and deployment admission rules. A report should distinguish missing provenance from invalid provenance.Match operating model to change rate.
Testing cadence is the interval between meaningful assessments. Weekly release teams may benefit from PTaaS workflows, while a major cloud redesign or high-risk AI agent may justify a focused manual engagement.Check evidence quality.
Audit-ready evidence is a finding package that includes reproduction steps, affected assets, business impact, remediation guidance, retest results, and clear severity rationale. Ask for a sample redacted report and confirm whether researchers remain available to engineering and audit teams.
A useful engagement should not stop at configuration review. Researchers should attempt realistic abuse paths, such as changing a workflow trigger, exploiting an overly broad cloud role, substituting an artifact, bypassing an environment approval, or influencing an AI agent to access deployment credentials.
Manual business logic testing evaluates how controls interact across multiple systems rather than checking isolated configuration values. This matters when a valid GitHub token, approved artifact, and permitted deployment action can be combined into an unintended privilege escalation.
Provider fit also depends on reporting requirements. Buyers preparing for SOC 2, ISO 27001, DORA, HIPAA, or PCI DSS should confirm that reports support auditor review, remediation tracking, and unlimited retesting where required. Human availability is important when developers need to clarify a finding during a release.
FAQ
Is OIDC a replacement for SLSA provenance?
No. OIDC establishes workload identity during a workflow. SLSA provenance provides evidence about how an artifact was built. Mature controls use both.
Should every GitHub Actions workflow receive cloud credentials?
No. Only workflows with a defined deployment or infrastructure need should receive federated access. Production credentials should use narrow claims and protected environments.
Which provider type is best for a B2B SaaS or AI product?
It depends on risk and operating model. PTaaS fits recurring standardized testing, a global firm fits broad enterprise programs, and a boutique manual provider fits focused testing of complex business logic, AI agents, cloud paths, and supply chain controls.
For buyers comparing engagement models, the pentest vendor scorecard provides a practical evaluation framework, and Sayfer is one option for researcher-led manual testing of these risks.
Top comments (0)