Great call out here and noted!

The fork network feature was often more a problem than a solution. The UI did not and probably still does not show where a single commit belongs to.

But that is just one of many things that I see and would like to see some changes.
Here is one more: aquasecurity/trivy#10425 (reply in thread)

There is a big gap between what the frontend shows and what other parts show when some error ocurs.
Not the only design flaw but one that makes it harder for users using the UI instead of the API and other interfaces.

And I guess (and highly hope), that any newly added uses entry with a unreferenced action in dependencies will lead to a failing pipeline run similar to how the other tools work when strictly installed from and veryfying against lockfiles.

And I guess (and highly hope), that any newly added uses entry with a unreferend action in dependencies will lead to a failing pipeline run similar to how the other tools work when strictly installed from and veryfying against lockfiles.

@DanielRuf That is correct. If an new uses entry is added without pining, the workflow will not run.

One thing I have been considering is a new setting that will globally require pinning for an enterprise, org, or repo. My concern is that it will cause many to workflows to fail without ensuring that teams have had time to pin dependencies. This isn't something we'd ship in an early phase, but curious what others think.

The hard part with these “all or nothing” settings is onboarding teams at scale.

If there was a way to make it apply to new or modified workflows, then it’s easier to drive adoption with less developer pain.

If there was a way to make it apply to new or modified workflows

I will look into this 😄 We take a similar approach to policy by applying new standards to new repositories and don't touch existing repos.

More detail on the proposed solution, along with a demo of what we have so far has been posted in this discussion: https://github.com/orgs/community/discussions/194494

We'd ❤️ your thoughts and opinions on the direction!

👋 thanks for commenting and highlighting this current behavior. We acknowledge the issue of workflow run logs being able to be deleted by any GITHUB_TOKEN with actions:write permission. After seeing this exploited in a number of supply chain attacks, I bounced the idea off the team of special casing this actor (the GitHub Actions bot) and preventing it from accessing this API. In our review however, there are valid use cases for workflows to delete workflow runs and logs (like cleaning up artifact storage space, etc), so we haven't shipped this change.

That said, with the forthcoming "Actions Data Stream" we are looking to make this new data stream the immutable source of truth for what workflows ran and what they did, replacing workflow run logs in their use for security investigations. While we are still actively tracking and discussing limiting the ability for the GITHUB_TOKEN to delete workflow runs, I think this new feature will fill this gap in incident response visibility.

And there is also the part with log retention. That is much shorter for the normal GH instances compared to GH enterprise.

I know, log management costs disk space and other resources. But could there be at least an option to use your own SIEM and configure some central repo setting, so that all logs are also sent to it? Many companies already use some solution for log collection, aggregation and analysis.

We were asking our GitHub manager(s) about the feature to keep the Actions logs optionally for more than 400 days (current max for Enterprise cloud).
Our company works under some regulations and even centralized logs not always what auditors ask us about. They want to see the logs on GitHub ecosystem for some use cases and with only 400 days it becomes for us more difficult to pass the audits.

Yes, storage costs the money, but if its an option which some companies ready to choose and pay for, it would be the option which helps us a lot with passing the external audits.

Appreciate the thoughts on this! We are starting with the CLI to get running as soon as possible 😄

I like the idea of getting this built into the PR flow. This is an avenue we need to explore, along with augmenting the existing YAML authoring experience to accommodate locking.

This portion of the experience is not set in stone and I am open to suggestions to make sure we get this experience right the first time. Keep the suggestions coming!

Ahhh @offensive-actions got it first above ^^

It is the most unituitive thing and everybody I show that to just looks at me like what 😅 Normally I understand where things are coming from, but I really struggle to see the upside of this behaviour. If there is any reason to do it like this I would love to learn about it :) Especially since there is no easy way (like one call) to check in the API if the commit belongs to an (even deleted!!) fork...

Thank you both for raising this, 100% noted and under discussion as we revisit Action dependency resolution and how we pin (and what we allow to be pinned). It is critical that these dependencies can clearly and accurately be used to determine the source of this code and allowing imposter commits make this impossible. If a workflow is compromised and the source of the dependency being loaded changes to an attacker controlled one, we have to make sure this is very clear.

Normally I understand where things are coming from, but I really struggle to see the upside of this behaviour.

There is really no upside 😄 The backstory here is unrelated to Actions dependencies, but instead broad architectural behavior about git at GitHub. All commits across parents and forks are stored in a "repo network," any commit is accessible across that network unless we do specific reachability checks for that commit in a repo. We do not do reachability checks by default, only in certain places where we specifically check it, like that "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository" warning you get in the web ui.

We had an attempt a few years ago to do this reachability check in Actions resolution, but ran into a number of existing usage of the current behavior for releases on branches, etc that lived in forks and it was decided not to break these use cases. Now with an opportunity to revisit this and be more opinionated about it, we can make dependency resolution more obvious and trustworthy.

Sounds awesome :) Thanks for giving some backstory!

I would love to get natively from GitHub something like Chainguard done to replace PATs by implemented "octo-sts"

Oh my god YES! We built something very similar to OctoSTS about a year before they did and still using it, but it would be so much better to have it as core platform !

I’m sure @mattmoor would be on board 😄

You're absolutely right, @fproulx-boostsecurity!

EDIT: fixed for humor 😉

@mattmoor We had a conversation with Dan L. from your team yesterday. Looking forward to future discussions!

@Steve-Glass Yeah, he told me. Very happy to discuss if/how we (or Chainguard) can help here.

Immutable Releases does not solve the same issue as Github Action

💯 This is something we plan to address this year. We have a few approaches we've been investigating. Each has their own potential impact to authors that we do not take lightly. I will share more detail in this thread over the next few weeks.

Yeah, I hoped immutable action publishing would finally resolve the problem of git to not checkin the dist folder (as a action author) and to not checkout the whole repo like including the tests of an action (as a action user), but to only get the minified binary from a real immutable package registry, like the planned OCI registry or from the GitHub release assets.

Another feature we were requesting from GitHub to add something like "Artifact attestations"/provenance enabled by default for all Actions run logs, as it could help with our audits when we can prove that logs which we saved via what ever implementation, like webhooks, are actually from GitHub, are not tampered, not artificially generated, etc.
As there is currently no native way to prove logs were created on GitHub
But some Logs/Data streaming solutions are appreciated.
I hope GitHub will not stop with only S3/"Azure".

I hope GitHub will not stop with only S3/"Azure".

We plan on meeting customers where they are at. It is not difficult to create new event sinks. We will work with early preview customers and and expand the list. Expect way more support leading up to GA. If there are any you'd like to see out the gate, let me know!

Came here to make this same kind of request.

I'd really like for Actions to be supported as core policy dimension, on top of Actor Rules and Event Rules. Supporting Actions as a dimension of policy for Actions would allow infinitely more capable and flexible governance, often required by enterprises and difficult or impossible to achieve natively in Actions today.

Supporting Actions as a dimension of policy that must succeed prior to the execution of further workflows or jobs (essentially a "pre-hook" or "pre-flight check") would allow

• applying OPA policies on workflow YAML contents (restrict specific runners from being used, etc.)
• blocking insecure or undesirable workflows from executing, using zimzor or a similar scanning tool
• blocking workflows from executing if a repository is using dependencies with critical vulnerabilities
• enforcing a more flexible and real-time allow-list for Actions that are allowed to be used, supporting malware scanning and vetting of Actions before they execute (not possible with the current Actions allow-list)

If this were also expanded to support enforcing policies after workflows or jobs (essentially a "post-hook"), it could support additional types of governance and compliance checks, including

• requiring that a job or workflow have produced some output, like test results or coverage info, and validate the contents
• requiring a security or compliance check to execute that depends on some dynamic workflow output (test results, coverage info, etc.)

Ideally any Actions used as policies would allow

• failure that blocks further execution for the job(s) or workflow(s)
• warning that notifies users but continues
• approval gate that requires users with specific roles to review and approve or deny

While Actions as a dimension of policy can be partially achieved with required and reusable workflows, it is difficult to actually implement and very limited functionally (hard to enforce prior to execution of user-defined workflows, or requires gating Actions behind only reusable workflows managed at the organization or enterprise level). Dynamic pre and post checks that are enforced at an organization or enterprise level and that depend on or integrate with user-defined Actions workflows are really what is needed to support a wide range of governance requirements.

Some of these ideas may be more along the lines of enterprise governance and policy enforcement than solely security, but they are critical for enterprises to secure and govern their use of GitHub Actions.

Reading through this again, I think most of my feedback here would fit better under a "governing Actions at scale" topic rather than this one specific to securing Actions. The ideas most specific to securing Actions would be

• enforcing OPA policies on Actions workflows prior to their execution
• scanning Actions for vulnerabilities and malicious intent, using the new workflow-level dependency locking proposed in the roadmap
• configuring specific Actions to execute and requiring them to succeed prior to executing workflows ("pre-hook"), which could support the first two items

@wrslatz I really like you ideas around pre and post job policy hooks! In addition to Event and Actor rules we are building, there was a list of about 10 other rules we scoped.

Like @deiga stated We want to block execution of Ubuntu-latest is one of them. More around the ability to limit execution based on runner type (hosted vs. self-hosted, standard vs. larger runner) and even repository visibility. Rather than build a bunch of rules nobody wanted, we wanted to start with capabilities that had strong signal and work with the community from there.

@wrslatz I really like you ideas around pre and post job policy hooks! In addition to Event and Actor rules we are building, there was a list of about 10 other rules we scoped.

Like @deiga stated We want to block execution of Ubuntu-latest is one of them. More around the ability to limit execution based on runner type (hosted vs. self-hosted, standard vs. larger runner) and even repository visibility. Rather than build a bunch of rules nobody wanted, we wanted to start with capabilities that had strong signal and work with the community from there.

@Steve-Glass starting with a smaller set of rules that are more applicable to a wider group makes sense. Being able to apply policy without needing to write custom Actions or code is really appealing.

It would be awesome if these new policy rules integrated well with the VS Code Actions workflow editing experience and/or a CLI experience. Catching and blocking these kinds of things prior to actually pushing changes up to GitHub would be great.

If OPA policy could be supported as native rules somehow and not require custom Actions workflows that would likely cover a lot of use cases. For example, I may want to enforce that workflows for Node.js projects use npm ci instead of npm install, as the preferred and more secure installation method in CI. Open to other ideas besides OPA for how to ensure CI/CD workflow best practices are followed where the content within the workflow YAML needs to be checked. We'll basically want to be able to enforce policy on any YAML content.

I love idea of "native support of OPA", as Rego is kind of industry standard for policies as code and several vendors support native integration. It extremely flexible and could help a lot with many policies to enforce on "content" of workflow files and not only workflows, but just any files on the repo which Enterprises need to control.

Another user proposed extending the interpretation of CODEOWNERS or adding a new repository setting.

Another user proposed workflow editing and execution as individual permissions on actors.

Currently developers are forced to use GitHub Apps or PAT and fail to protect such secrets in Actions, in certain common use cases including cross-repository access.

Recent major succeeded supply chain attacks used static secrets, and it can be scoped with the improved secret functionality. However, I wonder what if we can avoid using such static secrets for GitHub API. I've seen a lot of use cases that requires PAT or GitHub Apps secret key to achieve cross-repository workflows. Ephemeral secrets via OIDC is becoming a standard, but GitHub still lacks enough support to reduce such insecure API tokens in Actions, for GitHub APIs.

OIDC for apps and users would help a lot

Any trigger is a potential vector: a contributor can add or modify a push, schedule, or workflow_dispatch trigger on a feature branch and run an arbitrary workflow with access to repository secrets.

Schedules in non-default branches do not trigger, but any branch can create a new push workflow or add the workflow_dispatch trigger to an existing workflow along with arbitrary semantic changes.

A repository-level restriction by ref or CODEOWNERS would satisfy my use case.

I cannot say if the enterprisey nature of this proposal would work for @giom-l, but a ref or CODEOWNERS restriction could be viewed as an indirect way of authorizing the user identities that the restriction implicitly or explicitly excepts. More direct authorization would also be sufficient for my use case.

It's not clear to me how workflow editing would be prevented by this scheme when a developer has write access, but this may be ignorance of Enterprise features on my part.

Edit: I forgot that the original announcement mentioned rulesets as the basis for this feature, possibly enhanced to block pushes based on a combination of file path and user identity.