drift-testing
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If aimed at production, generated tests could create, modify, or delete real API data.
The skill may guide execution of state-changing API contract tests against a user-provided server URL; the artifacts disclose the risk and give mitigation guidance.
If `--server-url` points at a live production API, DELETE and POST tests are permanent. Always use a dedicated test account and confirm any resource used in a DELETE test is disposable.
Run against a mock, staging, or disposable test account by default, and review destructive tests before execution.
A failing or destructive test could be retried many times, causing repeated writes/deletes or noisy traffic.
A repeated feedback loop is purpose-aligned for test debugging, but repeated API calls can compound state changes or load if pointed at a shared or production service.
Use when the user wants full endpoint coverage, wants all tests to pass, or asks to "keep running until everything passes" ... `scripts/run_loop.sh` ... retries `drift verify --failed` until all tests pass
Set a retry/iteration limit when using loops, confirm the target environment, and avoid running destructive suites against shared production resources.
Using unpinned latest tooling can change behavior over time or inherit upstream supply-chain risk.
The CI example installs a latest remote binary into a system path; this is expected setup guidance for the Drift CLI but is unpinned.
wget -O - https://download.pactflow.io/drift/latest/linux-x86_64.tgz | tar xz -C /usr/local/bin
Pin Drift/Prism versions in CI, verify checksums or signatures when available, and prefer project-local installs where practical.
Mis-scoped or leaked tokens could allow unintended API access or PactFlow publishing.
The skill documents use of API and PactFlow tokens; this is expected for authenticated testing and result publishing, but those credentials are sensitive.
token: ${env:API_TOKEN} ... PACTFLOW_TOKEN="your-api-token" ... it needs publish permissions.Use least-privilege test tokens, store them only in environment variables or CI secrets, and prefer dedicated system accounts over personal tokens.
Internal API schemas, endpoints, and test results may be uploaded to PactFlow.
The documented PactFlow workflow sends verification results and the OpenAPI spec to an external provider, which is purpose-aligned for BDCT but may contain internal API details.
pactflow publish-provider-contract ... --verification-results ./drift-results/verification-bundle.json ... --spec openapi.yaml
Publish only intended specs/results, avoid embedding secrets in examples or test output, and confirm the PactFlow workspace and token scope before publishing.