Changelog
Harden-Runner GitHub Action v2.21.1
A maintenance release that tightens when the disable-sudo-and-containers policy takes effect and fixes a post-job cleanup failure on some Linux distributions.
Bug Fixes:
Improved enforcement timing of
disable-sudo-and-containersduring agent startup, so the policy is in effect earlier in the job.Fixed a post-job cleanup failure on certain Linux distributions.
See the v2.21.1 release on GitHub.
Webhook Integration: Multiple Endpoints per Tenant
Feature: You can now configure up to ten webhooks per customer, each with its own endpoint and its own event subscriptions. Until now a tenant had a single webhook, so every event type it subscribed to went to the same place. You can now send runtime detections to your SIEM and audit logs to a separate log archive, without either receiver having to filter out traffic it did not want.
Highlights:
Up to ten webhooks per customer. Click Add Webhook to add another endpoint. With more than one configured, each becomes a collapsible card showing its name, endpoint, and a chip for every event type it receives, so the routing across your endpoints is visible at a glance.
Independent connection settings per webhook. Endpoint URL, HTTP method, headers, and message format are set per webhook rather than once for the tenant. Each endpoint can therefore get the payload shape and the authentication headers it expects, including a different Envelope template per receiver.
Event subscriptions per webhook. Each webhook chooses from four event types: Insights, Detections, Secure Registry Audit Logs, and API Audit Logs. Any combination is valid, so one endpoint can take insights and detections together while another takes audit logs only. API audit log events require audit logging to be enabled for your tenant.
Repository scope per webhook. Repository selection is configured on each webhook, so one endpoint can be scoped to a subset of repositories while another covers all current and future repositories. Secure Registry and API audit log events are tenant-scoped and are delivered regardless of repository selection.
Independent delivery. Every webhook subscribed to an event type receives its own copy of that event. A failure at one endpoint does not affect delivery to the others.
The master Enable Webhook Integration toggle still controls the integration as a whole, and Save changes applies every webhook on the page at once.
PAT Governance for GitHub and Azure DevOps
Personal access tokens are now evaluated continuously against a policy you set, on both GitHub and Azure DevOps organizations. Tokens that breach the policy appear as findings on the All Controls dashboard, with the evidence, the impact, and a revoke action on each token.
Features
Token controls. Each control is enabled independently and evaluated against your token inventory every hour.
Thresholds you set. Max age and idle windows are configurable per organization. GitHub sets separate limits for fine-grained and classic tokens; Azure DevOps sets a stricter limit for tokens holding high privilege scopes. Both send pre-expiry reminders to token owners at configurable bands, 30, 7, and 1 days by default.
Scope risk, classified for you. On Azure DevOps, tokens are flagged against the 35 scopes Microsoft rates high privilege, with scope chips colour coded so an over-privileged token is visible without reading every scope. On GitHub, coarse classic scopes such as
repo,admin:org, andworkfloware flagged, along with fine-grained tokens combining all-repository access with write permissions.Notifications per control. Events fire once when a token starts breaching the policy, rather than on every scan, and are selectable individually.
Identities & PATs for Azure DevOps. A new page inventories everything holding access to your Azure DevOps organization: personal access tokens, service connections, and Entra service principals. Data is read from the Azure DevOps APIs, refreshes hourly, and can be refreshed on demand or exported per tab.
Dev Machine Guard Notifications
Dev Machine Guard detections now raise notifications. Seven new events on the tenant Notifications page alert you when a developer machine reports something new or suspicious.
Features
Seven new notification events. A new IDE, a new IDE extension, a new AI agent, a new MCP server, a new agent skill, a suspicious file, and a package manager configuration change. Each is enabled independently
Per-device notifications. Each device that reports a matching detection raises its own notification. Detections are not aggregated into a fleet-wide summary, so every notification points to a single machine to investigate
See Notifications.
ARC Harden Runner v2.19.0
This release brings the deny list egress policy to ARC Harden Runner, closing the gap with the Harden-Runner GitHub Action and Self-Hosted VM Harden Runner, and makes the image pull policy configurable through Helm values.
Features
Deny list egress policies. ARC Harden Runner now enforces deny list policies, which block specific destinations while leaving everything else reachable. Deny lists are managed centrally through the Policy Store, so a policy attached to a Cluster scope applies to every job in that cluster with no workflow file changes. Until this release, a deny list policy attached to an ARC cluster was not enforced.
Configurable image pull policy. The image pull policy for the ARC Harden Runner and Tetragon images is now set through Helm values, so clusters that pre-pull images or run behind a constrained registry no longer pull on every pod start:
env:
imagePullPolicy: IfNotPresent
tetragon:
imagePullPolicy: IfNotPresentDev Machine Guard v1.16.0
This release adds two new inventories to the device scan: where a developer machine's tools keep credentials, and which extensions its browsers hold. It also closes gaps in AI agent and MCP coverage, so machines running Pi, Factory Droid, Amp, OpenCode, or a gh-installed Copilot CLI are no longer reported as clean simply because the agent could not see them.
Features
Credential location inventory. A new scan phase reports which developer tools on the machine hold credentials, where those credentials sit, and how well each location is guarded. It covers thirteen sources across cloud (AWS credentials, AWS config, GCP application default credentials), source control (SSH private keys, the git credential store,
.netrc, GitHub CLI hosts), package registries (.npmrc,.pypirc), containers (Docker config, kubeconfig), and infrastructure (Terraform credentials, Vault token). Each finding carries the location, how many credentials it holds, whether the material is usable as-is or wrapped, the file mode on macOS and Linux, and whether the file sits inside a git repository and is tracked by it, which is the case worth acting on first. The credential itself never leaves the device: no value, no substring, no digest, and no fingerprint. Every location is an exact path rather than a directory to walk, every read is size capped, and a location the agent could not read is reported as an error rather than as clean, so an unreadable file can never be mistaken for an empty one.Browser extension inventory. The agent now inventories extensions installed in Google Chrome, Microsoft Edge, and Mozilla Firefox on macOS, Windows, and Linux, including Firefox under snap and flatpak and Edge under flatpak. Per extension it records identity (id, name, version, manifest version), whether it is enabled and who disabled it (user, browser, or policy), how it was installed (from a store, sideloaded, registry installed, unpacked, or policy installed), which store it is attributed to and whether that store still lists it or has flagged it, Firefox signature state, and the host and API permissions the browser is currently honouring, including which sites the extension can inject scripts into. Permissions a developer has withheld are not counted, so the inventory reflects what an extension can actually do rather than what it asked for. Only the browsers' own extension state files are read: browsing history, cookies, saved passwords, page content, and profile names are never collected, no browser is launched, and no extension store is contacted.
Improvements
Pi, Factory Droid, and Amp now appear in the AI agent inventory. All three were already discovered under Agent Skills but were missing from the AI agent and tool inventory, so a machine running them looked like a machine that was not. Each is now proven from an on-disk artifact (an npm or Bun manifest, an installer anchor directory, a Homebrew cask root, a WinGet publisher directory, or a pacman file manifest) rather than by binary name, because
pi,amp, anddroideach collide with a popular unrelated tool of the same name. Detection searches the prefixes a global install actually lands in, including the per-version trees of nvm, fnm, mise, volta, and asdf. Amp and Pi report a version read from disk, orunknown, and are never executed to obtain one.Two new agent skills roots.
~/.config/amp/skillsand~/.agent/skillsare now scanned, the second being singular.agent, which is distinct from the~/.agentsconvention already covered. See Agent Skills.Copilot CLI installed through
ghis now detected.gh copilotdownloads the Copilot CLI into the GitHub CLI's own data directory, which never reachesPATH, so machines where a developer letghinstall Copilot previously reported no Copilot CLI at all. Seven additional install locations are now checked after aPATHlookup misses, covering thegh copilotdownload on both platforms, the non-root install script path, the WinGet and npm global shims, and thegh-copilotextension. Machines that already resolvecopilotthroughPATHare unaffected. See IDE & AI Agents.OpenCode MCP servers are now collected. OpenCode declares servers under a top level
mcpkey rather thanmcpServersand accepts bothopencode.jsonandopencode.jsonc, including comments and trailing commas, so its servers were previously invisible to the MCP inventory. Global configs are now read from~/.config/opencode/opencode.jsonandopencode.jsonc, resolved against the developer's home directory, and project level configs are found by the existing bounded search. The secret allowlist is unchanged and remains deny by default, so OpenCode'senvironmentandheadersblocks are never collected. See MCP Servers.Secrets held in MCP server command, argument, and URL fields are now redacted before the MCP inventory is reported.
macOS consent checks now cover the new detection paths. The AI CLI detection ladders check TCC consent before each file system probe and again on every resolved symlink, so a scan on macOS no longer touches a protected path without consent. The pnpm and fnm trees under
~/Librarystay in scope, so both macOS installation channels are still detected.
See the v1.16.0 release on GitHub.
Mint StepSecurity API Tokens from AWS Workloads
Feature: OIDC federation now supports AWS as a provider, so workloads running in your AWS account can call the StepSecurity API without a stored API key. Until now, federation was available to GitHub Actions workflows only, and anything running outside GitHub Actions needed a long-lived key.
Highlights:
Provider selector on trust policies. Every trust policy now starts with a provider choice, either GitHub Actions, where workflows prove repository, ref, and environment through the GitHub OIDC token, or AWS, where workloads prove their IAM role through AWS identity federation. The policy form shows the identity fields for the provider you pick.
Match on AWS identity. An AWS policy matches on the issuer URL of your account's outbound federation, the 12-digit AWS account ID, and optionally the workload's role ARN. Leave the role ARN blank to trust any role in the account, or name a role to pin the policy to a single workload. Session names and role paths are ignored.
Covers workloads outside CI. Anything that can request a token from AWS STS can use this, including EKS, EC2, and Lambda.
Same lifetime and permission controls as GitHub Actions policies. AWS policies also set a max session duration and an allowlist of permissions, so a minted token is capped and scoped the same way.
The AWS provider is available for organization-scope trust policies. T
See Which Threat Center Incidents Affect You
Feature: StepSecurity now evaluates every Threat Center incident against your environment and flags the ones you are exposed to, so your team can focus on the incidents that actually apply to you instead of triaging the full feed. A new Affecting You filter and a You are affected badge surface your exposure at a glance, and each affected incident breaks down exactly where the match was found.
Highlights:
Affecting You filter. Switch between All incidents and the Affecting You view, each with a live count, at the top of the Threat Center.
You are affected badge. Incidents that touch your organization are badged in both views, so exposure is obvious straight from the list.
Matched components. Each affected incident lists the compromised packages found in your repositories, broken down per repository by whether the match is in an open pull request or on the default branch, down to the affected files, head commit, and matched version.
Matched IOCs. Indicators of compromise from an incident, such as a malicious network endpoint, are correlated against your Harden-Runner runtime data, with a per-run breakdown of the repository, workflow, job, and run that observed each call.
Notifications scoped to your exposure. Pair this with threat intel notification granularity to alert only on incidents that affect you. Choose Affected packages or Exact version only in Notifications to narrow alerts to your own dependencies.
Harden Runner Releases: August 17, 2026
This release bundle introduces the deny list egress policy across the Harden-Runner GitHub Action and Self-Hosted VM Harden Runner, adds AWS CodeBuild custom image support, improves containerized runner detection, and fixes wildcard endpoint and domain matching across deployment options. It covers the Harden-Runner GitHub Action v2.21.0, Self-Hosted VM Harden Runner v1.9.0, Self-Hosted VM Harden Runner v1.1.16 for persistent hosts running multiple runners, and ARC Harden Runner v2.18.7.
Harden-Runner GitHub Action v2.21.0
Features:
Deny list egress policy. A new
denied-endpointsinput blocks specific destinations while leaving all other destinations reachable, so you can stop traffic to known-bad or unwanted hosts without first building a complete allow list. Setegress-policy: blockand list the destinations you want denied:
egress-policy: block
denied-endpoints: |
example.com
*.example.orgDeny lists can also be managed centrally through the Policy Store, so you can apply and update them without editing workflow files.
Improvements:
AWS CodeBuild custom image support. Harden-Runner now supports AWS CodeBuild runners that run Linux containers on EC2 compute, which covers the custom image scenario.
Bug Fixes:
Corrected port matching for wildcard endpoints in block mode.
Fixed inconsistent port matching for wildcard domain policies.
Domain matching in policies and DNS lookups is now case-insensitive.
See the v2.21.0 release on GitHub.
Self-Hosted VM Harden Runner v1.9.0
Features:
Deny list egress policy.
denied_endpointsblocks specific destinations while leaving all other destinations reachable, withegress_policyset toblock. Deny lists can also be managed through the Policy Store without workflow changes.
Bug Fixes:
Corrected port matching for wildcard endpoints in block mode.
Fixed inconsistent port matching for wildcard domain policies.
Domain matching in policies and DNS lookups is now case-insensitive.
Self-Hosted VM Harden Runner v1.1.16 (persistent host, multiple runners)
Features:
Better detection of containerized runners. The agent now resolves runner details even when a job runs inside a container, so jobs on persistent hosts with multiple runners are attributed to the correct runner.
ARC Harden Runner v2.18.7
Bug Fixes:
Fixed a startup ordering issue in HTTPS and TLS monitoring that could cause a panic.
Fixed inconsistent port matching for wildcard domain policies.
Domain matching in policies and DNS lookups is now case-insensitive.
Miscellaneous stability fixes.
Secure Registry Now Supports Go
Feature: Go joins npm, PyPI, Maven, and NuGet in Secure Registry, in Beta. Point the Go toolchain, your CI runners, or your artifact repository manager at https://registry.stepsecurity.io/go and every module request is evaluated against your Go policy before a response is returned.
Highlights:
Cooldown Period holds newly published module versions for a window you set, with per-module exemptions written against the full module path
Compromised Packages blocks module versions that StepSecurity's SOC or the wider security community has flagged
Custom Block List bans a module or a version range org-wide in
module@versionform, with glob supportReleased Tags Only is new and specific to Go. Listed modules can only be resolved at a published release tag, so commit hashes, branch names, and pseudo-versions such as
v0.0.0-20241114170450-2d3c2a9cc518are refusedTyposquatting Protection shows as Not applicable for Go, because a module path is a repository location rather than a name in a shared namespace
Integration paths cover JFrog Artifactory, Sonatype Nexus Repository, and Direct
Checksum verification is unaffected. Leave
GOSUMDBat its default. If your runners cannot reachsum.golang.org, the new Proxy Checksum Database setting under Go Registry Settings relays those requests through Secure Registry instead of requiring you to disable verificationEvery Go module request lands in the Policy Evaluations log as Allowed, Modified, or Blocked, attributed to the developer machine or workflow run behind it
Self-Hosted Runners: Full Fleet Visibility and a New GitHub App Permission
Feature: The Self Hosted Runners page now builds a single inventory of every self-hosted runner in your organization, not just the ones already running the Harden-Runner agent. StepSecurity now also reads the runners registered in GitHub, at both the organization and repository level, and merges them with agent-reported runners into one consolidated view. The result is that runners which are registered in GitHub but have never reported in from the agent are now visible as registered and unmonitored, which is exactly where runtime coverage gaps hide.
Action required: Listing organization-level runners requires a new Self-hosted runners: Read-only organization permission on the StepSecurity GitHub App. If your organization installed the app before August 10, 2026, GitHub has already sent you a pending permission request. An organization admin needs to approve it under Organization Settings → GitHub Apps before organization-level runners appear in the inventory. We recommend accepting it so you get the full picture of your fleet. Until it is approved the page still works and continues to show repository-level runners, so nothing you have today stops working.
This permission is read-only. StepSecurity can list runners and read their metadata. It cannot register, modify, remove, or take runners offline.
Highlights:
Runners discovered from GitHub, not only from the agent. Runners registered at the organization level and at the repository level are now pulled from the GitHub API and listed alongside runners reported by the Harden-Runner agent. Runners are also picked up from workflow run insights when Harden-Runner monitored a job on them
One entry per runner. A runner is often visible to more than one discovery source, so records are merged rather than duplicated, and each runner shows the Source it was discovered from
Coverage gaps become obvious. Because registration and agent presence are shown side by side, a runner registered in GitHub with no agent installed now stands out in the Harden Runner column as Not installed
Scope at a glance. Runners are badged with their registration scope, either Org or Repo with the repository name, along with Persistent or Ephemeral lifecycle
Filter and search the fleet. Search by runner name or label and filter by status, and see when runner data was last synced with the option to refresh on demand
Per-runner detail. Selecting a runner opens a details panel whose fields reflect how it was discovered, covering agent version and install time for agent-reported runners, and level, OS, runner group, labels, and observed job counts for runners registered in GitHub
Full documentation, including how an admin approves the pending permission request, is in Self-Hosted Runners.
Harden Runner Releases- August 5, 2026
This release bundle covers the latest updates across Harden Runner deployment options, including the Harden-Runner GitHub Action v2.20.1, ARC Harden Runner v2.18.6, and Self-Hosted VM Harden Runner v1.8.14, along with the first versioned release of Runner Job Hooks, v1.0.0.
Harden-Runner GitHub Action v2.20.1
Features:
AWS CodeBuild-hosted runner support. Harden-Runner now supports GitHub Actions runners hosted on AWS CodeBuild.
Single-labeled internal domains are now implicitly allowed in block mode. Single-labeled hostnames, meaning internal names that contain no dot, are allowed automatically when
egress-policy: blockis set. They no longer need to be listed inallowed-endpoints.
See the v2.20.1 release on GitHub.
ARC Harden Runner v2.18.6
Features:
Container process tracing (opt-in). Process events from inside the container on ARC pods are now captured as well. Enable it through Helm values:
env:
enableContainerProcessTracing: "true"Single-labeled internal domains are now implicitly allowed in block mode. Internal hostnames that contain no dot are allowed automatically in block mode, without being listed in the allowed endpoints.
Improvements:
Policy enforcement is now more responsive under load.
Self-Hosted VM Harden Runner v1.8.14
Features:
Single-labeled internal domains are now implicitly allowed in block mode. Internal hostnames that contain no dot are allowed automatically in block mode, without being listed in the allowed endpoints.
Bug Fix:
Fixed process misattribution for network events.
Runner Job Hooks v1.0.0
Features:
Versioned job hooks are now publicly available. The GitHub Actions runner pre-job and post-job hooks are published at step-security/gha-runner-job-hooks, so runners can reference a specific hook version.
Hooks rewritten in TypeScript. The pre-job and post-job hooks were rewritten from shell script to TypeScript and JavaScript.
To configure hooks on your runners, go to Settings → Harden-Runner Installation → Runner Job Hooks in the StepSecurity app and follow the installation instructions there.
Threat Intel Notifications: Tenant-Wide Channels and Match Granularity
Feature: You can now choose how precisely StepSecurity threat intelligence notifications match your environment, and configure notification channels once at the tenant level instead of per organization. Threat intel alerting is now an explicit opt-in event with three granularity levels, so security teams can track every ecosystem incident while application teams hear only about the packages they actually use.
Highlights:
Three match granularity levels. Threat intel notifications now support All threat intel incidents, which alerts on every incident whether or not you are affected, Affected packages, which alerts only when a compromised package matches by name at any version, and Exact version only, which alerts only when the exact compromised version is present. Set the level from the Threat intel notifications dialog after enabling the event
Tenant-wide notification channels. A new Notifications page under Admin console settings configures email, a Slack webhook, and a Teams webhook once for the whole tenant, rather than repeating channel setup in every connected organization. Granularity is selectable at the tenant level as well, so a tenant can subscribe to the full incident feed independently of how individual organizations are configured
Explicit opt-in per organization. Threat intel alerting is now controlled by the Notify when StepSecurity threat intel flags a compromised component event in organization notification settings, alongside the existing Harden-Runner detection events. The current granularity selection is shown inline beneath the event and can be changed at any time
Threat intel notifications cover the same incidents surfaced in the Threat Center, including the compromised packages or Actions involved and the recommended remediation steps.
Dev Machine Guard v1.15.0
This release delivers the device side of today's Device Policy launch: the npm package config lane, private marketplace enforcement for VS Code, and a verify-only channel for profiles your MDM enforces. It also moves scan cadence control to the StepSecurity platform, and completes Homebrew detection on scans that run without a developer's shell environment.
Features:
Scan cadence is now controlled from the StepSecurity platform. Scan frequency is set once in Dev Machine Guard settings, defaulting to every 4 hours, and the agent gates every invocation against it: on each run it checks with the backend whether a scan is due, and exits without scanning if it is not. Your scheduler or MDM now decides only how often the agent wakes up, while the platform decides whether that wake-up scans, so you can change cadence across the whole fleet without redeploying anything to devices.
Temporary scan frequency boost. You can raise the scan cadence for a limited window with an expiry, after which devices automatically revert to the standard frequency. During a malicious package disclosure you can dial the cadence up for a few hours and not have to remember to undo it afterwards.
npm package config enforcement on the device. The agent converges a StepSecurity-owned block in the console user's
~/.npmrc, so npm, and the pnpm, Yarn classic, and bun tools that read the same file, resolve packages through your tenant's Secure Registry. The lane stays dormant until apackage_configpolicy is assigned to the device: an absent policy is a no-op, never a wipe. Writes are transactional, with snapshot rollback and bounded, identity-checked backups.Private marketplace URL enforcement for VS Code. When a policy sets a gallery URL, the agent writes
extensions.gallery.serviceUrlinto user-scopesettings.jsonin the same atomic write asextensions.allowed. Removal is ownership-gated, so a gallery URL the developer configured themselves is never deleted. An allow-list-only policy writes exactly as it did in previous versions.Verify-only enforcement channel for MDM-enforced profiles. On profiles your MDM enforces, the agent never writes. It reads the OS-managed VS Code policy (Windows registry, macOS managed preferences,
/etc/vscode/policy.json) or the effective~/.npmrc, and reports the observed values along with the channel the cycle actually ran under, so the dashboard compares drift like for like. An unrecognized channel falls back to the enforcing path rather than skipping enforcement. The npm reader never returns or logs a token, hash, or fingerprint, and reports an observed plaintexthttp://registry as drift evidence.
Improvements:
Homebrew installed outside
PATHis now detected.brewis resolved from the standard install locations (/opt/homebrew,/usr/local,/home/linuxbrew) and its version is read from Homebrew's repository metadata instead of by invokingbrew --version, so formula and cask inventory is complete on scans that run without the developer's interactive shell environment.Managed
settings.jsonfiles that begin with a UTF-8 byte order mark are now enforceable. A file seeded by PowerShell 5.1Set-Content -Encoding UTF8, or by an editor configured forutf8bom, previously parsed as invalid and stayed unenforceable indefinitely.Device policy ownership for every category is now recorded in a single locked state file, so one category clearing its policy can no longer drop another category's ownership record.
Bug Fixes:
Credentials in malformed index URLs containing more than one
@are now fully masked in effective-config telemetry. The user info was previously split at the first@, so a mangled pip index URL could ship its trailing credential verbatim.Policy clears report a removal only when something was actually removed. An unassigned device no longer announces a cleared managed block on every cycle.
See the v1.15.0 release on GitHub.
Device Policy: Package Config Policies, MDM Verification, and Private Marketplace
Feature: Device Policy now controls which package registry developer machines resolve from, not just which IDE extensions they can install. Profiles declare how they are enforced, and when your MDM enforces a profile, Dev Machine Guard continuously verifies what your MDM actually deployed on each device and reports any drift with an exact field-by-field diff.
Highlights:
Package config policies for npm: a new policy category that configures npm on each assigned device to resolve packages through your tenant's Secure Registry. The policy writes a clearly marked managed block into the developer's
~/.npmrcwith the registry URL and an authentication token, bounded byBEGINandENDmarkers so any surrounding configuration is left untouched. The tenant registry token is shared, but each device receives a per-device::dev:suffix, so registry access is attributed per machine. This replaces per-machine setup with a policy you define once and deliver to the whole fleet. PyPI, covering the pip and uv index, is listed in the ecosystem selector as coming nextMDM verification with field-by-field drift diffs: profiles enforced through your MDM are now continuously verified. The agent never writes in this channel. It reads each device, compares what your MDM actually deployed against the policy, and reports one of eight states per policy category, including MDM verified, MDM drift, Not deployed, and Verification failed. When a device drifts, the diff shows desired against observed for every field: which extensions are missing, which were deployed but are not in the policy, which have changed version constraints, and whether the extension gallery URL matches. Resolve drift by fixing the deployment in your MDM or by updating the policy to match
Audit, remediation, and uninstall scripts for MDM-delivered package config: because
.npmrcis user-writable and drifts back the moment a developer edits it, package config policies generate a script set per platform rather than a one-shot configuration profile. Deploy the audit and remediation pair together into the detection and remediation slots of Intune Remediations or an Iru Custom Script library item, and let your MDM's own check-in cadence run them. An uninstall script removes the managed block and restores any registry line it had commented out, for offboarding or when detaching the policyPrivate marketplace for IDE extension policies: point assigned devices at a self-hosted extension gallery instead of the public Visual Studio Marketplace by setting an optional gallery URL on the policy. It compiles to
extensions.gallery.serviceUrland ships in the same artifact as the rest of the policy. Allow-list and block-list enforcement is identical either way, and the gallery URL is itself verified, so a device pointed at an unexpected gallery reports driftExplicit enforcement type per profile: every profile now declares whether your MDM enforces it or the Dev Machine Guard agent enforces it, shown as a Verify only or Self healing badge. Both types require device assignment. Switching an existing profile between types moves every assigned device onto the new channel, and devices report Pending until each agent checks in under it
NuGet Ecosystem Support in GitHub Checks, OSS Package Search, and Secure Registry
Feature: GitHub Checks, OSS Package Search, and Secure Registry now support the NuGet (.NET) ecosystem alongside npm, PyPI, and Maven, so .NET teams get the same PR enforcement, blast-radius search, and install-time controls already available for the other ecosystems.
Highlights:
GitHub Checks: two new PR Content Security controls. NuGet Package Compromised Updates blocks pull requests that introduce or update a NuGet dependency flagged in StepSecurity's compromised-packages database, and NuGet Package Cooldown blocks pull requests adding recently published NuGet versions until they age beyond the configured cooldown window. Both can be set to Required or Optional, like the npm, PyPI, and Maven controls
OSS Package Search: NuGet is now selectable from the Package ecosystem toggle. NuGet packages are indexed from GitHub repositories and pull requests, parsed from
*.csproj,*.vbproj,*.fsproj,packages.config,packages.lock.json,Directory.Packages.props,Directory.Build.props, and*.deps.json. Onlypackages.lock.jsonrecords transitive dependencies, so enable NuGet lock files if you need indirect dependencies coveredSecure Registry, NuGet ecosystem (Beta): point .NET clients at
https://registry.stepsecurity.io/dotnet/index.jsonand every NuGet metadata request and package download flows through Secure Registry for evaluation, the same way npm, PyPI, and Maven requests already do. NuGet joins the Registry selector on both the Policy and Setup Guide tabs, with policy configured independently per ecosystemNuGet control coverage: Cooldown Period, Compromised Packages, and Custom Block List are available at launch. Typosquatting Protection for NuGet is marked Coming soon
Three integration paths for NuGet: JFrog Artifactory, Sonatype Nexus Repository, and Direct. On the Direct path, a Package manager selector switches the instructions between the .NET CLI, the NuGet CLI, and Visual Studio
V3 protocol only: the service index is served at
/dotnet/index.json, with resources under/dotnet/v3/. The deprecated V2 (OData) protocol is not supported. Clients select V3 automatically, because NuGet picks its protocol from the source URL suffixPolicy Evaluations: the Ecosystem filter now includes .NET, so you can narrow the audit log to NuGet requests and trace each one back to the developer machine or CI run behind it
Known limitation: NuGetAudit is not supported yet. Secure Registry does not proxy the VulnerabilityInfo resource, so audit-enabled restores emit NU1905. Disable the audit for the restore with -p:NuGetAudit=false, or exclude the Secure Registry source from your audit sources.
Secure Registry: Maven Support in Beta, Custom Block List, and Tarball URL Rewriting
Feature: Secure Registry now supports the Maven (Java) ecosystem in Beta, adds a Custom Block List control for blocking specific packages and versions outright, and adds a Tarball URL Rewriting setting for npm.
Highlights:
Maven ecosystem (Beta): point Maven at
https://registry.stepsecurity.io/javaand every Maven metadata request and artifact download flows through Secure Registry for evaluation, the same way npm and PyPI requests already do. Maven joins npm and PyPI in the Registry selector on both the Policy and Setup Guide tabs, with policy configured independently per ecosystemAll four integration paths for Maven: JFrog Artifactory, Google Artifact Registry, Sonatype Nexus Repository, and Direct. A new Package manager selector on the Setup Guide switches the integration steps to match your client
Maven control coverage: Cooldown Period and Compromised Packages are available at launch Custom Block List and Typosquatting Protection for Maven are marked Coming soon
Custom Block List: a new per-ecosystem control that blocks specific packages or versions from being served, regardless of publication date or compromise status. Patterns are matched as globs (for example,
lodash@4*,@scope/*), so you can block a single version, a version range, an entire package, or a whole scope. Use it to enforce internal bans on packages your security team has rejected. The control is evaluated independently of Cooldown, Compromised Packages, and Typosquatting ProtectionTarball URL Rewriting (npm): a new setting in the npm Registry Settings panel that rewrites the tarball URLs in npm metadata responses so package downloads route through Secure Registry instead of the public npm registry
Workflow Run Policies: allow-list enforcement, runner constraints, and richer policy insight
This release expands every Workflow Run Policy type and adds deeper visibility into how policies evaluate each run.
Compromised Actions Policy
The policy editor now shows the compromised actions the policy checks for, under Currently known compromised actions, including whether all versions or only specific versions of each action are affected. The list is maintained by StepSecurity and updates automatically as new compromises are verified.
Policy evaluations now record the compromised actions list as it existed at the time of each run, so you can always reconstruct why a run was or was not blocked.
Secret Exfiltration Policy
New Block only when a workflow accesses all secrets at once mode (recommended) blocks bulk secret access patterns such as
${{ toJSON(secrets) }}while leaving targeted references such as${{ secrets.NPM_TOKEN }}unblocked, dramatically reducing false positives.New Analyze default branch runs option extends the policy to workflow runs on the default branch. Pair it with the bulk-access mode to cover all branches while limiting the blast radius.
Violation details now include the secret reference that triggered the block and its line number in the workflow file.
Runner Label Policy
New Allowed labels & constraints (allow list) mode: only labels and constraint values on the list may be used, with each configured dimension enforced independently. The existing disallowed-labels mode is unchanged.
Runner constraints support structured
runs-onkeys (the runs-on.com scheme:family,cpu,image,ami,volume, and so on), enabling enforcement for third-party runner providers such as RunsOn. Expression values are matched by their exact text.
Harden-Runner Policy
New Require policy store option: targeted jobs must set
use-policy-store: trueon their Harden-Runner step so the runtime policy comes from the StepSecurity policy store.New Block jobs running in a container option: blocks targeted jobs that set a job-level
container:on GitHub-hosted standard runners, where Harden-Runner cannot monitor outbound calls from inside the container.
Policy evaluation visibility
Customizable PR Comment Template per policy, with placeholders including
{{policy_name}},{{policy_details}},{{remediation}}, and{{docs_url}}.The Policy Evaluations page now shows an evaluation status for every run (Allowed, DryRunBlocked, or Blocked), a per-policy breakdown of violations, a link to the related PR, and run policy timing metrics covering webhook receipt through cancellation.
Workflow run insights now include a Workflow Run Policy Evaluation section on the Summary tab, covering blocked, allowed, and no-policy states, including for cancelled runs where runtime insights could not be generated.
Harden-Runner insights
The Network Events tab now shows how many suppression rules applied to each job, with a View suppression rules link listing them, making it easy to audit why an expected detection does not appear.
Agent Skills Inventory for Developer Machines
Feature: Dev Machine Guard now inventories AI agent skills installed on developer machines. A new Agent Skills page in the dashboard shows every skill detected across your fleet, which AI agents can load it, where it came from, and whether it contains executable content.
Agent skills are folders containing a SKILL.md file that AI coding agents like Claude Code, Codex, and GitHub Copilot load to perform specialized tasks. Skills can ship scripts, register lifecycle hooks, and embed shell commands that run with the developer's user privileges, making them a growing supply chain surface on developer machines.
Highlights:
Fleet-wide inventory: every detected skill with the agents that can load it, its installation scope (
Global,Project, orSystem), the number of devices it is installed on, and per-device installation detailsExecutable content flags: skills are flagged when they ship executable script files (
code), declare a hooks block that runs on lifecycle events (hooks), or inject shell commands that execute when the skill loads (shell)Provenance: skills installed through the skills.sh CLI trace back to their source GitHub repository, plugin, and upstream folder hash; standalone skills are marked as authored on device
Version drift detection: content hashes of each skill's
SKILL.mdare compared across devices, and skills that are not identical on every device are highlighted so you can spot outdated or locally edited copiesFiltering and export: filter by source (skills.sh managed or local), agent, scope, and flags, search by skill name, and download the full inventory with Export CSV
New Control: Jobs Should Use a Secure Registry Instead of Public Package Registries
Feature: A new control on the Overview dashboard checks whether CI/CD jobs download packages through a secure registry instead of public package registries.
The check passes if the job's network baseline contains no calls to public package registries such as registry.npmjs.org, pypi.org, or registry-1.docker.io. Routing package downloads through a secure registry protects CI/CD jobs from malicious or compromised packages published to public registries.
Like all controls, findings are listed on the control detail page, where you can filter by repository, workflow, and compliance status, track remediation, and suppress findings that don't apply. To remediate, configure the job's package managers to use a secure registry (e.g., StepSecurity Secure Registry, JFrog Artifactory, Sonatype Nexus) instead of the public registry.
Actions Secret: Usage Tracking, Secret Status, and OIDC Replaceability
Feature: The Repository Secrets tab in the Actions Secret section now shows how each secret is used and whether it can be replaced with OIDC, alongside the existing rotation tracking.
Highlights:
Summary cards: Total Secrets, Unused Secrets, Stale Secrets, and OIDC Replaceable counts give you an at-a-glance view of your repository secrets posture
Usage tracking: each secret shows a Usage Status (
Active,Stale,Unused, orUnknown) and the workflows that reference it, including the workflow file, the step that uses the secret, the last run time, and the run conclusionOIDC replaceability: secrets that can be replaced with OpenID Connect authentication are flagged, such as an
NPM_TOKENthat npm trusted publishing can replaceFiltering: search by repository or secret name, filter by status, or show only OIDC-replaceable secrets
See Actions Secret
Dev Machine Guard v1.13.0
This release makes Device Policy enforcement through the DMG agent generally available and expands what the agent can discover on developer machines.
Features:
Device Policy enforcement through the DMG agent is now generally available. The agent now enforces Device Policy profiles by default, with no MDM required. Assign a profile to all devices or specific ones from the dashboard, and the agent installs and continuously enforces the approved VS Code extension set on each device. Agents pick up assignments on their next cycle. See the Device Policy documentation.
Classic Visual Studio discovery. Dev Machine Guard now discovers classic Visual Studio installations and their extensions, extending IDE extension inventory beyond VS Code and other modern IDEs.
Disk-based package scanning for npm and Python. Installed packages are now scanned directly from disk, using lockfile parsing for npm and dist-info metadata for Python, with a scan cache and concurrent workers for faster runs. The previous scanning method remains available via the
use_legacy_package_scanopt-out.
Improvements:
Scans can now also run at login, with improved scheduling reliability and scheduler diagnostics.
Expanded global package discovery, including pnpm v10+ globals and Yarn classic globals on Windows.
See the v1.13.0 release on GitHub.
Harden Runner Releases- July 7, 2026
This release bundle covers the latest updates across Harden Runner deployment options, including the Harden-Runner GitHub Action v2.20.0, ARC Harden Runner v2.18.4, and Self-Hosted VM Harden Runner v1.8.12.
Harden-Runner GitHub Action v2.20.0
Features:
Block policy support for macOS and Windows GitHub-hosted runners. The
egress-policy: blockmode is now supported on macOS and Windows GitHub-hosted runners, so outbound traffic on these runners can be restricted to allowed endpoints, not just audited.Support for Bitrise macOS GitHub Actions runners. Harden-Runner now works on Bitrise-hosted macOS runners for GitHub Actions.
HTTPS monitoring support for Bun on Linux runners. Workflows that use the Bun runtime on Linux runners now get HTTPS request monitoring (enterprise tier).
See the v2.20.0 release on GitHub.
ARC Harden Runner v2.18.4
Improvements:
Improved reliability of TLS library discovery.
Miscellaneous stability fixes.
Bug Fix:
Fixed an issue where TLS probes were not detached correctly during teardown.
Self-Hosted VM Harden Runner v1.8.12
Feature:
HTTPS monitoring support for Bun on Linux amd64 runners. Workflows that use the Bun runtime on Linux amd64 self-hosted VM runners now get HTTPS request monitoring.
Improvements:
Improved reliability of TLS library discovery.
Bug Fix:
Fixed an issue where TLS probes were not detached correctly during teardown.
New Detection: Secret Exfiltration Attempt
Feature: Harden-Runner now detects workflow runs that attempt to exfiltrate repository secrets. This is a new detection type on the Detections page, alongside existing detections such as Secrets in Build Logs, Anomalous Outbound Network Calls, and Agent Tampered.
Recent supply chain campaigns steal a developer's GitHub token, commit a malicious workflow, and use the run to read every repository secret with toJSON(secrets) and ship them out as an artifact. The Secret Exfiltration Attempt detection flags these runs as they execute, so you can rotate exposed secrets before they are retrieved.
Highlights:
Indicator-based detection — a run is flagged when the indicators of a secret-exfiltration attack appear together, including a workflow name matching a known attack pattern, a
toJSON(secrets)pattern that dumps all repository secrets, a commit message matching the attack's pattern, and an exfiltration artifact written by the runConfidence scoring — each detection is assigned a confidence level. If the workflow run, branch, or workflow file is deleted shortly after running, confidence is raised to High, since removing the evidence is itself a strong indicator of an exploitation attempt
Direct navigation — each detection lists the affected repository, matched rule, indicators, workflow file, and the exact job, step, and line where the secret dump was found
Opt-in alerts — you can enable a notification for this detection in Notification Settings to be alerted the moment a flagged run occurs
See the Detections documentation.
StepSecurity Maintained Actions Are Now Free for Public Repositories
Feature: StepSecurity Maintained Actions, secure drop-in replacements for popular third-party GitHub Actions, are now free in public repositories. This was previously an enterprise-only capability.
All 500 maintained actions are free for public repositories with no subscription required. Private repositories still require a StepSecurity subscription.
See the documentation or the announcement blog post.
Secure Registry: Source Attribution, Typosquatting Protection, and Sonatype Nexus Support
Feature: Secure Registry now attributes every package request in the Policy Evaluations log to the developer machine or CI pipeline that made it, adds Typosquatting Protection as a configurable control, and supports Sonatype Nexus Repository as an integration path.
Highlights:
Source attribution — the Policy Evaluations log has two new columns, Source and Source Identifier, that trace each request back to its origin. Requests from a developer machine link to that device's page for inspection of its extensions, agents, MCP servers, packages, and suspicious files; requests from CI link to the corresponding Harden-Runner workflow run. Attribution is opt-in: append an identifier suffix to your API key token (
::dev:<DEVICE-SERIAL-ID>for developer machines, or agha:identifier for pipeline runs) as shown in the Setup GuideTyposquatting Protection — a new per-ecosystem control that blocks packages whose names closely resemble popular packages. A Whitelisted Packages allowlist lets you clear false positives by exact package name
Sonatype Nexus Repository — a new integration path in the Setup Guide for teams that proxy npm through Nexus, alongside the existing JFrog Artifactory, Google Artifact Registry, and Direct npm options
Two newly compromised GitHub Actions added to StepSecurity's blocklist
StepSecurity has added the following GitHub Actions to its maintained list of compromised actions:
codfish/semantic-release-actionsimonecorsi/mawesome
Both of these actions were compromised today. Given that two separate action compromises have already occurred within the same day, additional supply-chain attacks targeting GitHub Actions are expected in the near future.
Action required for enterprise customers
All enterprise customers should enable the Compromised Actions Policy. Once enabled, any usage of an action that StepSecurity has flagged as compromised will be immediately blocked across your workflows, with no manual intervention required.
When StepSecurity adds a newly compromised action to this list, customers with the policy enabled are protected automatically.
Learn more
See the Compromised Actions Policy documentation for setup instructions and policy details
Harden Runner Releases- June 24, 2026
This release bundle covers the latest updates across Harden Runner deployment options, including ARC Harden Runner v2.18.3 and Self-Hosted VM Harden Runner v1.8.11.
ARC Harden Runner v2.18.3
Features:
Broker pod customization in Helm. The resource broker template now honors common pod-spec fields so it can run alongside workloads with strict scheduling or registry requirements. New values are available under
broker.*:
volumeMounts: []
imagePullSecrets: []
automountServiceAccountToken: false
serviceAccountName: ""
resources: {}
nodeSelector: {}
tolerations: []
affinity: {}
topologySpreadConstraints: []Signed container images. Versioned and FIPS image manifests published to
ghcr.io/step-security/arc-harden-runnerare now signed with Cosign (keyless, OIDC). Verify thearc-harden-runnerimage:
cosign verify ghcr.io/step-security/arc-harden-runner/arc-harden-runner:v2.18.3 \
--certificate-identity-regexp 'https://github.com/step-security/arc-harden-runner/.*' \
--certificate-oidc-issuer https://token.actions.githubusercontent.comVerify the broker image:
cosign verify ghcr.io/step-security/broker/broker:v1.3.0 \
--certificate-identity-regexp 'https://github.com/step-security/broker/.*' \
--certificate-oidc-issuer https://token.actions.githubusercontent.comMaintenance:
Broker image bumped to
v1.3.0.
Self-Hosted VM Harden Runner v1.8.11
Bug Fix:
Fixed an issue for persistent-scenarios where
runnerWorkermemory-read detection was not being configured correctly.
Maven Ecosystem Support in GitHub Checks and OSS Package Search
Feature: GitHub Checks and OSS Package Search now support the Maven (Java) ecosystem alongside npm and PyPI, so teams can scan and search Maven dependencies with the same controls already available for the other ecosystems.
Highlights:
GitHub Checks — two new PR Content Security controls: Maven Package Compromised Updates, which blocks pull requests that introduce or update a Maven dependency flagged in StepSecurity's compromised-packages database, and Maven Package Cooldown, which blocks pull requests adding recently published Maven versions until they age beyond the configured cooldown window. Both can be set to Required or Optional, like the npm and PyPI controls
OSS Package Search — Maven is now selectable from the Package ecosystem toggle, letting you find where specific Maven packages appear across pull requests and default branches for blast-radius analysis and targeted remediation
Maven controls and search behave identically to their npm and PyPI counterparts, just evaluated against Java dependencies
Dev Machine Guard: Package Configs
Feature: A new fleet-wide audit of package-manager configuration on every enrolled developer machine, showing which registry each device actually resolves from, whether a cooldown policy is in effect, and how registry credentials are configured.
Highlights:
Effective registry — resolves the registry each device actually uses, accounting for configuration precedence across scopes, and shows where the value came from. Identifies machines resolving from an internal mirror versus those going directly to the public registry
Cooldown — flags devices not protected by a cooldown policy, and where the installed package manager is too old to support the control, indicates what to upgrade
Authentication surface — summarizes registry credentials per device, distinguishing tokens hardcoded into a config file from those referenced through an environment variable
Per-scope breakdown — selecting a device shows the effective configuration plus what each scope sets (for example,
GLOBAL /etc/npmrcandUSER ~/.npmrc), with registry, cooldown, and auth entries for eachMulti-ecosystem — covers
npm,pnpm,bun, andyarn(JavaScript) andpip(Python), auditing.npmrc,bunfig.toml,.yarnrc[.yml], andpip.conf; exportable to CSV
Dev Machine Guard: Suspicious Files Detection
Feature: Dev Machine Guard now detects malicious files planted by supply chain attacks across enrolled developer machines, using detection rules authored and maintained by StepSecurity. Works out of the box with no rules to configure.
Highlights:
Managed detection rules — files flagged by StepSecurity-maintained rules covering known supply chain campaigns, including the malicious
binding.gypused by the Miasma worm (the Phantom Gyp technique) and editor and AI-tool configuration files that auto-execute on project open or session start (.vscode/tasks.json,.claude/setup.mjs,.cursor/rules/setup.mdc, and others). Rules are updated centrally as new campaigns emerge, with nothing to configure on your endFleet-wide view — every flagged file across enrolled devices in one list, with the file, device, associated campaign, confidence level, and status
Filters — narrow by status, confidence, or campaign to focus on what matters during an incident
Detection details — selecting a file shows its full path, SHA-256, the matched rule and file-path pattern, and when it was first and last seen, plus a condition breakdown showing exactly which indicators matched and which were required
Threat Center: Retrieve Compromised Components per Incident via API
Feature: A new StepSecurity API endpoint returns all compromised open-source components tied to a specific Threat Center incident, so teams can pull incident data programmatically instead of reading it from the dashboard. Requested by multiple customers for automating triage and correlating compromised packages against their own dependency inventory.
Highlights:
New endpoint
GET /github/{owner}/threat-intel/incidents/{incidentId}/compromised-componentsreturns every compromised component for a given incidentEach component includes the package ecosystem (
type),component_name, affectedversion,severity,verifiedstatus,description,incident_group_id,added_at, andthreat_intel_idTakes your GitHub organization (
owner) and the incident identifier (incidentId) as path parameters; requires a valid StepSecurity API tokenFeed incident data into your own tooling, automate triage, or correlate compromised packages against your dependency inventory without scraping the dashboard
Secure Registry: PyPI Support Now in Beta
Feature: PyPI support in Secure Registry has been promoted from "coming soon" to Beta, so PyPI installs can now be proxied and evaluated against your configured security controls at install time, alongside npm.
Highlights:
PyPI ecosystem (Beta) — point pip at the Secure Registry URL and every PyPI metadata request and tarball download flows through Secure Registry for evaluation, the same way npm requests already do
Per-ecosystem policy — the Policy tab's Registry selector now covers both npm and PyPI, with controls (Cooldown Period, Compromised Packages, Exempted Packages) configured independently per ecosystem
PyPI requests appear in the Policy Evaluations log and are filterable by ecosystem alongside npm
Authentication Overhaul and Dev Machine Guard MDM Deployment
Feature: New authentication options for the StepSecurity API and a documented MDM deployment path for Dev Machine Guard on enterprise fleets.
Highlights:
Short-lived personal access tokens — Per-user, fine-grained bearer tokens with a maximum lifetime of 12 hours, for calling the StepSecurity API from scripts, CLIs, and the StepSecurity MCP server. Available from the top-right avatar menu under Short-lived tokens, or at app.stepsecurity.io/me/tokens
Fine-grained API keys (organization and tenant) — Scoped, long-lived service credentials bound to an organization or tenant, with permissions you select at creation time and expirations up to 1 year. Key value is shown once at creation; revocable at any time
OIDC federation for GitHub Actions — Trust policies that let workflows mint short-lived StepSecurity API tokens directly via OIDC, with no stored secret in the repository. Policies can be scoped on repository, branch, environment, and workflow file path. Available at both organization and tenant level
Embedded API reference (Swagger UI) — A new API reference tab on the StepSecurity API settings page, with the full OpenAPI 3.0 spec browsable and testable from the dashboard, plus a download link for use with code generators and Postman
Dev Machine Guard MDM deployment guides — A new MDM Deployment section under Installation Script, covering Windows and macOS fleet deployment patterns. Initial guides:
Windows via Microsoft Configuration Manager (SCCM) — full step-by-step guide for fleet rollout of the signed Dev Machine Guard MSI, including supersedence-based upgrades and Sigstore signature verification
macOS via Iru (formerly Kandji) — full step-by-step guide using Iru's Custom Script library item for daily execution of the loader script
Secure Registry: Cooldown Exemptions and Compromised Package Blocking
Feature: Two new controls in Secure Registry give customers finer-grained policy over which packages are blocked at install time.
Highlights:
Exempt packages from cooldown — allowlist specific packages (for example, internal scoped packages or trusted first-party publishers) so that new versions are served immediately, bypassing the configured cooldown window. Useful when an organization controls the publishing pipeline and does not need a vetting buffer for its own packages
Block compromised packages — deny installs of any package version flagged in StepSecurity's continuously updated compromised-packages database, even if the version is outside the cooldown window. Stops known-bad releases from reaching developer machines and CI/CD pipelines, regardless of cooldown configuration
Both controls are configurable per ecosystem and complement the existing Cooldown Period control that shipped at Secure Registry launch
New Control: Default branch should be protected
Feature: A new Source Code Integrity control evaluates whether each repository's default branch has branch protection enabled, surfacing unprotected default branches alongside the rest of the StepSecurity controls dashboard.
Highlights:
Flags repositories whose default branch has no branch protection rule, leaving it open to direct pushes, force pushes, and accidental deletion
Severity: High — an unprotected default branch bypasses code review and CI checks, and is a common precursor to supply chain incidents
Appears under Source Code Integrity in the All Controls view, with failed-check counts per repository
Aligns with the corresponding OpenSSF Scorecard check, so existing remediation guidance applies
Secure Registry: Authenticated Upstream Registry with Configurable Security Controls
Feature: Secure Registry is a new authenticated upstream registry that proxies package requests from developers, CI runners, and artifact repository managers, applying StepSecurity security controls before responses are returned.
Highlights:
New per-ecosystem Policy tab to toggle security controls. Cooldown Period available today; Compromised Packages and Typosquatting Protection coming soon
Cooldown Period blocks packages published within a configurable window (default 10 days), giving the community and StepSecurity's SOC time to vet new releases before they reach your environment
Three integration paths (JFrog Artifactory, Google Artifact Registry, and Direct npm (.npmrc)) covering teams with or without an existing artifact manager
Primary and Secondary API keys for zero-downtime rotation
New Policy Evaluations log records every request flowing through Secure Registry with per-control results, filterable by status, ecosystem, request type, package, version, and date range
Available for npm today; PyPI coming soon
Dev Machine Guard: System Packages with Linux Coverage and Risk Indicators
Feature: Dev Machine Guard expands OS-level package visibility beyond macOS Homebrew, adding Linux package detection across three formats and surfacing new risk indicators for unsigned and third-party packages.
Highlights:
System Packages page (renamed from Brew Packages) consolidates OS-level package inventory across macOS and Linux developer endpoints in a single view
Linux package detection covers three formats:
rpm,snap, andflatpakNew Vendor and Maintainer metadata surfaces the publisher and contact for each Linux package
New Unsigned filter flags packages with no cryptographic signature, and the Third-party filter flags packages not distributed officially by the device's Linux distribution
Package detail view shows per-version device counts so version drift is immediately visible across the fleet
PyPI Support Across OSS Package Security
Feature: PyPI joins npm as a first-class ecosystem across StepSecurity's OSS Package Security capabilities. Package search and GitHub Checks now cover Python dependencies alongside JavaScript ones.
Highlights:
OSS Package Search (formerly NPM Package Search) now supports both npm and PyPI ecosystems, with package detection unified across pull requests, default branches, and developer machines
Two new GitHub Checks for PyPI dependencies:
PyPI Package Compromised Updates blocks PRs that introduce or update PyPI dependencies known to be compromised
PyPI Package Cooldown blocks PRs that introduce recently-published PyPI packages, with a configurable cooldown window
Backed by the same StepSecurity SOC threat intelligence and AI Package Analyst verdicts already in use for npm
A unified investigation surface for cross-ecosystem incidents that affect both npm and PyPI
Replace Maintained Actions: New Replacement Modes and Major-Version Restriction
Feature: The Replace Third-Party Actions with StepSecurity-Maintained Actions policy in Policy-Driven PRs now supports two replacement modes and optional major-version matching.
Highlights:
New Replace selected actions mode (opt-in, default) — only replace actions you explicitly select
New Replace all, except exempted mode (opt-out) — replace everything with a StepSecurity-maintained equivalent automatically, except for listed exemptions
New Restrict replacement to same major version toggle — only replace when the third-party action's major version tag matches the StepSecurity-maintained action's major version
Reduces the operational cost of maintaining a large action allowlist while preserving organization-specific flexibility
Policy Store: Policy History and Audit Trail
Feature: The Policy Store now records every change to a policy in a timeline-view audit trail, with side-by-side diffs for content edits.
Highlights:
Timeline view of all policy changes — content edits, attachments, detachments, and scope modifications
Side-by-side diff view for YAML content changes, with added and removed lines highlighted
Attribution showing who made each change and when
Attachment-change events capture scope transitions (e.g., specific workflows → entire repo) so the full history is visible at a glance
Accessible from any policy's three-dot menu via View history
Designed to make policy-related changes easier to audit for security reviews and compliance
Harden-Runner Support for Third-Party GitHub Actions Runners
Feature: Harden-Runner (v2.19.0) now supports the four major third-party GitHub Actions runner providers: Depot, Blacksmith, Namespace, and Warp Build.
Highlights:
Same egress monitoring, runtime monitoring, and policy enforcement that Harden-Runner provides on GitHub-hosted runners
Integration is identical to GitHub-hosted runners — add
step-security/harden-runneras the first step of each job; only theruns-onlabel changesNo provider-specific configuration required
Supports Policy Store, block mode with
allowed-endpoints, and all standard Harden-Runner detectionsAlso in v2.19.0: system-defined detection rules for Lockdown Mode (e.g., runner-worker memory reads, a known secret-stealing technique) and Windows/macOS stability fixes
Dev Machine Guard: Expanded Platform and Ecosystem Coverage
Feature: Dev Machine Guard adds Windows support, a JetBrains IDE extension, Homebrew formulae coverage, and PyPI package detection — broadening supply-chain visibility on developer endpoints beyond macOS and npm.
Highlights:
Windows support — Dev Machine Guard now runs on Windows developer endpoints alongside existing macOS coverage, giving security teams a unified view across the platforms their developers actually use
JetBrains IDE extension — native integration with IntelliJ IDEA, PyCharm, GoLand, WebStorm, and other JetBrains IDEs, complementing the existing VS Code extension
Homebrew formulae support — detects risky, typosquatted, or newly published Homebrew formulae installed on developer machines, closing a gap that npm-focused tools miss
PyPI package detection — extends package-level risk analysis to the Python ecosystem, surfacing suspicious PyPI installs with the same AI Package Analyst verdicts used for npm
Unifies developer-endpoint visibility across three package ecosystems (npm, PyPI, Homebrew) and the two most common developer IDEs (VS Code, JetBrains)
Global Block List: Threat-Intelligence-Driven Automatic Blocking
Feature: Harden-Runner (v2.18.0) now enforces a StepSecurity SOC-maintained Global Block List of IOC domains and IPs across every protected workflow — automatically, and even in audit mode.
Highlights:
Outbound connections to known malicious domains and IPs are blocked automatically, with no configuration change required
Enforcement applies even in
egress-policy: auditmode — customers do not have to re-decide whether to block each IOCList is curated by StepSecurity's 24×7 SOC based on active supply-chain attack investigations
Used to block exfiltration from the pgserve npm compromise in real time
Blocked requests are labeled Attack Blocked in the Network Events view so customers can distinguish them from regular policy blocks
Also in v2.18.0: new
deploy-on-self-hosted-vminput for installing the Harden-Runner agent directly on ephemeral self-hosted Linux VMs at workflow runtimeFurther expanded in v2.19.0 (20 April 2026) — see above
Workflow Run Policies: Harden-Runner Policy and Pinned-Actions Enforcement
Feature: Two new policy enforcement capabilities have been added to Workflow Run Policies.
Highlights:
Harden-Runner Policy — blocks workflow runs where the Harden-Runner action is missing or is not configured as the first step of a job. Supports Custom Actions for organizations that wrap Harden-Runner inside an internal bootstrap action
Only allow pinned actions toggle on the Allowed Actions Policy — blocks any action reference that is not pinned to a commit SHA, protecting against tag-overwrite attacks like the
tj-actions/changed-filescompromiseWildcard support in the Allowed Actions Policy allowlist (e.g.,
actions/*)
Policy Store Integration in Harden-Runner Action
Feature: Harden-Runner (v2.17.0) adds native Policy Store support via new use-policy-store and api-key inputs.
Highlights:
Fetch and enforce security policies directly from the StepSecurity Policy Store at runtime
Policies can be attached at workflow, repository, organization, or ARC cluster level, with the most granular policy taking precedence
Preferred alternative to the existing
policyinput, which requiresid-token: writepermissionIf no policy is found in the Policy Store, the action defaults to audit mode
Centralize egress policy management across hundreds of repositories without editing any workflow file
Dev Machine Guard Open Source
Feature: Dev Machine Guard is now open source
Highlights:
Provides visibility into what is actually running on developer machines in real time
Helps security teams detect suspicious processes, hidden tooling, and unexpected network activity on developer endpoints
Enables developers and organizations to independently verify the security posture of their development environments
Supports supply chain defense by exposing processes that could manipulate builds, credentials, or CI/CD interactions
Fully open source, enabling community auditing, transparency, and contributions
Complements StepSecurity’s CI/CD protections by extending visibility upstream to developer workstations
Harden Runner Windows & macOS Support
Feature: Harden Runner now supports GitHub Actions runners on Windows and macOS.
Highlights:
Harden Runner delivers EDR-level runtime security across all three major GitHub Actions platforms: Linux, Windows, and macOS.
Cross-platform support includes network and process event monitoring out of the box, with no workflow configuration changes required.
Available in both Community Tier and Enterprise Tier; Windows and macOS monitoring remains free for public/open-source projects.
Same action and syntax as existing Harden Runner workflows — it now “just works” on Windows and macOS.
Apps & PATs Visibility
Feature: Launch of Apps & PATs — centralized visibility for GitHub Apps and Personal Access Tokens.
Highlights:
Provides organization-wide inventory of GitHub Apps and PAT usage
Helps security teams identify high-risk or overprivileged credentials
Detects dormant or unmanaged tokens that expand supply chain attack surface
Improves governance over third-party GitHub integrations
Supports least-privilege access enforcement beyond workflows
Strengthens identity-layer security in GitHub environments
StepSecurity Dark Mode
Feature: StepSecurity now supports Dark Mode across the platform UI.
Highlights:
Enables a more comfortable viewing experience for security and DevOps teams
Improves usability for long investigation and monitoring sessions
Supports modern UI accessibility preferences
Provides a consistent dark theme across dashboards, insights, and policy workflows
StepSecurity Developer Machine Guard
Feature: Introduction of StepSecurity Dev Machine Guard — protecting developer machines from supply chain attacks.
Highlights:
Secures developer endpoints as a critical part of the software supply chain
Prevents compromised laptops, credentials, and local tooling from becoming an entry point into CI/CD systems
Extends StepSecurity’s protection beyond workflows into developer environments
Helps organizations detect risky developer machine posture before code reaches production
Complements CI/CD runtime enforcement with upstream endpoint defense
Designed for modern engineering teams facing increasing developer-targeted attacks
Harden-Runner Support for GitHub-Hosted Custom Runner Images
Feature: Support for baking StepSecurity Harden-Runner directly into GitHub-hosted custom VM images.
Highlights:
Enables organization-wide runtime protection by embedding Harden-Runner into GitHub-hosted custom runner images
Eliminates the need to add the Harden-Runner action to individual workflows
Provides persistent, default-on runtime security for every job running on the custom image
Removes workflow-level operational overhead for large organizations with hundreds or thousands of workflows
Reduces developer friction by making CI/CD runtime security transparent and automatic
Enables centralized lifecycle management of Harden-Runner through runner image updates
Ensures consistent policy enforcement across all workflows when combined with the Policy Store
Supports gradual migration with no conflicts if existing workflows still include the Harden-Runner action
Aligns CI/CD security with infrastructure-level security practices used for production systems
StepSecurity on Azure Marketplace
Feature: StepSecurity is now available on the Azure Marketplace, adding a new procurement and deployment path alongside AWS Marketplace availability.
Highlights:
Purchase StepSecurity using existing Azure billing arrangements
Simplify vendor management with consolidated Azure invoices
Accelerate deployment inside Azure-hosted environments
Adopt StepSecurity’s CI/CD security for GitHub Actions with minimal configuration
Get end-to-end workflow visibility, automated egress control to prevent supply chain attacks, and enforcement of GitHub Actions security best practices
npm Package Search
Feature: Introduction of npm Package Search for PR-level visibility into when and where npm packages entered your codebase.
Highlights:
Provides instant search across all pull requests in your GitHub organizations to identify where an npm package was first introduced
Answers critical incident-response questions: Which repos are affected? Who added the package? When did it land? What’s the blast radius?
Tracks package lifecycle changes — even if a dependency was later removed, you can see when it existed, who added it, and how long it persisted
Enables correlation of developer activity, helping teams assess whether compromised developer machines or credentials may have played a role
Goes beyond traditional SCA by focusing not just on what you use today but how each dependency entered and evolved
Accelerates response to supply chain incidents like Shai-Hulud, Singularity, and eslint-config-prettier by instantly surfacing all PRs that introduced compromised package versions
Supports proactive dependency auditing to find deprecated, vulnerable, or policy-violating packages with full contextual history
Provides organization-wide blast-radius assessment to help teams prioritize remediation across multiple repositories
StepSecurity Threat Intelligence
Feature: Launch of Threat Intelligence — real-time supply chain attack alerting for your SIEM.
Highlights:
Provides immediate alerts when a major supply chain incident occurs.
Integrates with SIEM/SOC tools for instant threat visibility
Includes a Threat Center dashboard for tracking active and historical incidents
StepSecurity Artifact Monitor
Feature: Introduction of the StepSecurity Artifact Monitor.
Highlights:
Detects unauthorized or malicious software releases within minutes
Monitors artifact registries (like npm) to catch releases that bypass CI/CD pipelines
Verifies provenance using commit SHAs, tags, and build metadata
Sends alerts via Slack, email, or SIEM integrations
New Features for GitHub Actions Security Best Practices
Feature: Enhancements to the “Secure Repo” capability — new features to enforce GitHub Actions security at scale.
Highlights:
Support for pinning GitHub’s new “Immutable Actions” (semantic version pinning).
Introduced exemptions for pinning specific Actions or entire organisations.
Persistent user settings to apply best-practice preferences across multiple repositories automatically.
Internal GitHub Actions Marketplace
Feature: Launch of the Internal GitHub Actions Marketplace — a secure, enterprise-ready directory of vetted GitHub Actions.
Highlights:
Provides a curated marketplace of approved third-party and first-party GitHub Actions
Ensures only vetted Actions are used in CI/CD pipelines, reducing supply chain risk
Includes Action Security Scores, networking behavior insights, and repository usage visibility
Offers StepSecurity-maintained secure clones of risky third-party Actions
Enforces guardrails through Compromised Actions and Allowed Actions policies
Eliminates the burden of maintaining forked Actions internally
Harden-Runner Unified Network Egress Management
Feature: Unified network egress insights and outbound endpoint management for GitHub Organizations and Actions Runner Controller (ARC) clusters.
Highlights:
Adds a consolidated “All Observed Endpoints” view showing every outbound network destination contacted across all workflow runs
Provides organization-wide and cluster-wide visibility into suspicious or unexpected endpoints
Allows engineers to inspect sample workflow runs associated with any endpoint for rapid investigation
Makes outbound endpoint data for public GitHub organizations accessible for open-source transparency
Introduces Unified Network Egress Management for ARC clusters, including per-cluster endpoint views
Enables default cluster-wide network egress policies to block unauthorized outbound calls without modifying workflows
Automatically generates tailored deployment instructions to activate default egress blocking per ARC cluster
Ensures secure-by-default networking, with workflow-level allowed-endpoints lists overriding defaults only when explicitly set
Automatic Detection of Secrets in GitHub Actions Build Logs
Feature: Automated scanning of GitHub Actions build logs to identify exposed secrets.
Highlights:
Automatically downloads and analyzes completed workflow logs for secret exposure
Detects sensitive values such as API keys, passwords, private keys, and webhook URLs leaked during workflow execution
Flags violations in the “secrets should not be logged in the build log” control with masked secret previews and direct links to offending log lines
Provides enterprise-grade notifications via Slack, email, or Microsoft Teams
Displays an aggregated list of all “Secrets in build log” detections in the StepSecurity dashboard
Helps organizations prevent accidental credential leakage from tools like Azure CLI, AWS CLI, Google Cloud CLI, and misconfigured workflows
Demonstrated effectiveness during beta: uncovered real secret exposures across multiple GitHub organizations, prompting rapid remediation
Harden-Runner HTTPS Outbound Request Monitoring
Feature: Support for monitoring outbound HTTPS requests from GitHub-hosted and self-hosted VM runners.
Highlights:
Adds visibility into HTTP methods and paths for outbound API calls made over HTTPS
Detects anomalous or suspicious GitHub API usage, such as attempts to exfiltrate CI/CD secrets by creating issues or pushing content to unauthorized repositories
Improves accuracy of recommended GITHUB_TOKEN permissions by analyzing actual API calls made during workflow execution
Introduces a new HTTPS Events tab in Harden-Runner insights, showing all monitored outbound HTTPS calls with method, path, and organization context
Flags suspicious requests — for example, POST or PUT requests made to GitHub organizations different from where the workflow is running
Powered by eBPF monitoring of SSL writes, avoiding the operational overhead and fragility of MITM proxy approaches
Easily enabled through the StepSecurity dashboard for Team and Enterprise plans, with optional Slack and email notifications for anomalous events
Fully supported in Harden-Runner v2.7.0 for GitHub-hosted and VM-based runners, with ARC (Kubernetes) support coming soon
GitHub Actions Advisor & StepSecurity Maintained Actions
Feature: Launch of GitHub Actions Advisor and StepSecurity Maintained Actions to help organizations assess and reduce the risk of third-party GitHub Actions.
Highlights:
Introduces GitHub Actions Advisor, providing automated security scores for public Actions based on six attributes: maintenance status, vulnerabilities, popularity, branch protection, license, and security policy
Surfaces networking behavior for Actions using runtime data from Harden-Runner to identify outbound calls to suspicious endpoints
Helps security and DevOps teams understand risk across all Actions used in their GitHub organization
Eliminates tedious manual reviews and forks of low-quality or abandoned Actions
Launches StepSecurity Maintained Actions, secure forks maintained by StepSecurity with manual and automated review, upstream updates, and applied security best practices