Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🌱 Secure workflow stale.yml #1326

Merged
merged 5 commits into from
Nov 23, 2021
Merged

🌱 Secure workflow stale.yml #1326

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
ca4fd67
Update stale.yml
varunsh-coder Nov 22, 2021
f7f824e
Update stale.yml
varunsh-coder Nov 22, 2021
1c043be
Update stale.yml
varunsh-coder Nov 22, 2021
bde49ef
Update stale.yml
varunsh-coder Nov 23, 2021
8cba5c9
Merge branch 'main' into varunsh-coder-patch-2-1
naveensrinivasan Nov 23, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions .github/workflows/stale.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,10 +17,20 @@ on:
schedule:
- cron: "30 1 * * *"

permissions: read-all

jobs:
stale:
permissions:
issues: write
pull-requests: write
runs-on: ubuntu-latest
steps:
- uses: step-security/harden-runner@7206db2ec98c5538323a6d70e51f965d55c11c87
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What value add does this step-security/harden-runner? So that it restricts access the action to only certain FQDN?

What if there is a vulnerability within the step-security/harden-runner? What kind of data is being sent to agent.api.stepsecurity.io:443?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @naveensrinivasan the value add as of now is to prevent exfiltration of credentials and detect compromised components in the supply chain. As an example, when the Codecov bash uploader was compromised, credentials were sent out to 2 IP addresses and were not detected for months. Or as in the dependency confusion attack, DNS exfiltration was used to send metadata out. As more features are added, the value add would be to provide runtime security for GitHub Action hosted runner...

step-security/harden-runner and the step-security/agent it installs are both open source. The data it sends out is network information and process information. You can see the source code and the output here. W.r.t vulnerability, yes, that is a risk, but that is true for all GitHub Actions and all components used in the supply chain. To reduce the risk, the goal of step-security/harden-runner is to set a baseline and restrict network, process, and file activity on the runner.

Please let me know if this addresses your concerns. Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @naveensrinivasan the value add as of now is to prevent exfiltration of credentials and detect compromised components in the supply chain. As an example, when the Codecov bash uploader was compromised, credentials were sent out to 2 IP addresses and were not detected for months. Or as in the dependency confusion attack, DNS exfiltration was used to send metadata out. As more features are added, the value add would be to provide runtime security for GitHub Action hosted runner...

Could you tell us more about how the restrictions put in place by step-security/harden-runner are guaranteed not to be undone by code that manages to get RCE in the action? Say, in the firewalling rules: can the malicious code undo the rules? Why not?
The firewalling code does allow 8.8.8.8: why can the malicious code not send packets to it, and only the agent can?

step-security/harden-runner and the step-security/agent it installs are both open source. The data it sends out is network information and process information. You can see the source code and the output here. W.r.t vulnerability, yes, that is a risk, but that is true for all GitHub Actions and all components used in the supply chain. To reduce the risk, the goal of step-security/harden-runner is to set a baseline and restrict network, process, and file activity on the runner.

Please let me know if this addresses your concerns. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @laurentsimon w.r.t restrictions being undone, to undo the firewall rules or to stop the agent itself, a malicious action would need to run sudo. One of the future features would be to recommend if sudo can be disabled for that job (because it is not used) and do so. If it cannot be disabled, then detect the use of sudo in a way not in the baseline.

W.r.t sending to 8.8.8.8, that is a great question. Malicious code can do that, and will not be stopped, but it will get detected. The service side creates a map of process activities per step, and if a step was not supposed to call 8.8.8.8, and does, it will get detected. In fact, I have been thinking about whether to have a detect and alert only system or also do restrictions for outbound calls. Restrictions are not going to be per step though, they can only be for the whole job...

Hope that answers your questions.

with:
allowed-endpoints:
agent.api.stepsecurity.io:443
api.github.com:443
- uses: actions/stale@cdf15f641adb27a71842045a94023bef6945e3aa # v3.0.18
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Expand Down