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.

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

Improve rule checks #13

Open
TomHennen opened this issue Jan 10, 2025 · 1 comment
Open

Improve rule checks #13

TomHennen opened this issue Jan 10, 2025 · 1 comment

Comments

@TomHennen
Copy link
Contributor

Right now the rule check in actions/vsa_creator/determine_source_level_gh.sh doesn't check

a. That the rule has enforcement active
b. That the user hasn't made other changes to the code prior to this revision with the rule deactived.

Currently the spec doesn't really address (b) but it probably should in some way.

A quick proposal for what we could do here:

  1. Get the ruleset ID for the rules we care about from the rules API call.

e.g.

$ curl -L   -H "Accept: application/vnd.github+json"   -H "X-GitHub-Api-Version: 2022-11-28"   https://api.github.com/repos/TomHennen/slsa-source-poc/rules/branches/main
[
  {
    "type": "deletion",
    "ruleset_source_type": "Repository",
    "ruleset_source": "TomHennen/slsa-source-poc",
    "ruleset_id": 3184000   # <-- use this
  },
  {
    "type": "non_fast_forward",
    "ruleset_source_type": "Repository",
    "ruleset_source": "TomHennen/slsa-source-poc",
    "ruleset_id": 3184000   # <-- and this
  }
]
  1. Use the rulesets API to get the details about those rulesets (they could be different!)
$ curl -L   -H "Accept: application/vnd.github+json"   -H "X-GitHub-Api-Version: 2022-11-28"   https://api.github.com/repos/TomHennen/slsa-source-poc/rulesets/3184000
{
  "id": 3184000,
  "name": "no-force-push",
  "target": "branch",
  "source_type": "Repository",
  "source": "TomHennen/slsa-source-poc",
  "enforcement": "active",
  "conditions": {
    "ref_name": {
      "exclude": [

      ],
      "include": [
        "~DEFAULT_BRANCH"
      ]
    }
  },
  "rules": [
    {
      "type": "deletion"
    },
    {
      "type": "non_fast_forward"
    }
  ],
  "node_id": "RRS_lACqUmVwb3NpdG9yec42arxDzgAwlYA",
  "created_at": "2025-01-07T14:10:13.659Z",
  "updated_at": "2025-01-09T22:13:35.296Z",
  "_links": {
    "self": {
      "href": "https://api.github.com/repos/TomHennen/slsa-source-poc/rulesets/3184000"
    },
    "html": {
      "href": "https://github.com/TomHennen/slsa-source-poc/rules/3184000"
    }
  }
}
  1. Check that .enforcement is active (protects 'a' above)
  2. Check that .updated_at is at least X days in the past. (provides some protection for 'b' above).

It seems like this should be possible to do with jq and more shell scripting, but maybe someone would be interested into turning this into something more formal?

@TomHennen
Copy link
Contributor Author

I think there's an outstanding question about what 'X' should be for check '4'.

When chatting about it with @adityasaky I suggested '90 days' for Level 2, but it might be possible to go much shorter if we wanted to. It will require some thought.

For now, in this PoC, maybe we'd prefer to keep it simple and say '7' days or something like that? That should make it easier to see progress in the near term.

TomHennen added a commit that referenced this issue Jan 24, 2025
This introduces a golang CLI that determines the level instead of using shell scripts.

It also implements the ideas in #13 to ensure the rulesets are active and have been active for a sufficient length of time.

The go program introduced here:

1. Checks that deletion and non-fast-forward rules exist.
2. That they are active within a certain about of time of the provided commit being pushed to the branch.

It also starts to introduce support for producing and signing the VSA with Sigstore, but currently stops short because it got too complicated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant