You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The PSModule framework pins third-party GitHub Actions by SHA in workflow and action files (e.g., actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd) and uses Dependabot to propose updates. However, there is no mechanism to detect unexpected drift — where a pinned SHA no longer matches its claimed version tag, or where a dependency has been yanked, deprecated, or compromised.
Request
Current experience
Action SHAs are pinned inline with version comments (e.g., # v6.0.2). Dependabot opens PRs when newer versions are available, but:
There is no verification that the pinned SHA actually corresponds to the claimed tag
If a tag is force-pushed (rewritten), the SHA comment becomes misleading
There is no inventory of all third-party dependencies across the organization's actions
Internal PSModule actions (e.g., PSModule/Install-PSModuleHelpers@ed79b6e3...) are pinned by SHA but not tracked by Dependabot
Desired experience
A periodic CI job (or pre-merge check) that:
Inventories all pinned action SHAs across workflow and action files
Verifies each SHA still corresponds to the tagged version in the comment
Detects internal PSModule action pins that have fallen behind their latest release
Reports drift as a PR comment or issue
Acceptance criteria
All third-party action SHAs are verified against their claimed version tags
Internal PSModule action SHAs are checked against their latest release tags
Drift is reported clearly (which file, which action, expected vs actual)
The check runs periodically (e.g., weekly via schedule) and on PRs that modify workflow files
Note
This aligns with Twelve-Factor App Factor II (Dependencies) — explicitly declare and isolate dependencies. Pinning by SHA is the declaration; drift detection is the ongoing verification that declarations remain accurate.
Technical decisions
Approach: Create a scheduled workflow that:
Uses grep or a script to extract all uses: lines with SHA pins from .github/workflows/*.yml and action repos
For each entry, queries the GitHub API to resolve the tag mentioned in the comment to a SHA
Compares the resolved SHA with the pinned SHA
Reports mismatches
Scope: Start with the Process-PSModule repository's workflow files. Expand to action repositories (Build-PSModule, Publish-PSModule, etc.) in a follow-up.
Reporting: Output as a GitHub step summary. Optionally create an issue if drift is detected.
Implementation plan
Create a Check-DependencyDrift.yml workflow with schedule and workflow_dispatch triggers
Implement SHA-to-tag verification script (PowerShell or shell)
Add internal PSModule action version checks
Generate step summary with drift report
Test with a deliberately mismatched SHA to verify detection
The PSModule framework pins third-party GitHub Actions by SHA in workflow and action files (e.g.,
actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd) and uses Dependabot to propose updates. However, there is no mechanism to detect unexpected drift — where a pinned SHA no longer matches its claimed version tag, or where a dependency has been yanked, deprecated, or compromised.Request
Current experience
Action SHAs are pinned inline with version comments (e.g.,
# v6.0.2). Dependabot opens PRs when newer versions are available, but:PSModule/Install-PSModuleHelpers@ed79b6e3...) are pinned by SHA but not tracked by DependabotDesired experience
A periodic CI job (or pre-merge check) that:
Acceptance criteria
schedule) and on PRs that modify workflow filesNote
This aligns with Twelve-Factor App Factor II (Dependencies) — explicitly declare and isolate dependencies. Pinning by SHA is the declaration; drift detection is the ongoing verification that declarations remain accurate.
Technical decisions
Approach: Create a scheduled workflow that:
grepor a script to extract alluses:lines with SHA pins from.github/workflows/*.ymland action reposScope: Start with the
Process-PSModulerepository's workflow files. Expand to action repositories (Build-PSModule,Publish-PSModule, etc.) in a follow-up.Reporting: Output as a GitHub step summary. Optionally create an issue if drift is detected.
Implementation plan
Check-DependencyDrift.ymlworkflow withscheduleandworkflow_dispatchtriggers