Feature: mis-configured OIDC

[laurentsimon]

See https://medium.com/tinder/identifying-vulnerabilities-in-github-actions-aws-oidc-configurations-8067c400d5b8

[spencerschrock]

Is this something in the source repo, or in AWS/cloud provider? Would we be able to detect it?

[laurentsimon]

Great question. It would likely require a cloud credential to scan the settings. I'm not 100% sure if it falls under Scorecard. I'd like Scorecard to be able to do the scan since it's related to SDLC / supply-chain, but we need to discuss further if we're OK (or not) to take as input a new set of (cloud) credentials. Thoughts?

[spencerschrock]

Great question. It would likely require a cloud credential to scan the settings. I'm not 100% sure if it falls under Scorecard. I'd like Scorecard to be able to do the scan since it's related to SDLC / supply-chain, but we need to discuss further if we're OK (or not) to take as input a new set of (cloud) credentials. Thoughts?

If we can't detect misconfiguration from the repo side, I'm inclined to say it's not in scope of Scorecard.

[laurentsimon]

I'm leaning in the other direction because the bug is related to SDLC / CI, which is in scope for Scorecard. In would be sub-optimal to ask users to use a different tool for it. That said, the broader cloud security scanning is out of scope of Scorecard, so I'm only considering this in scope because it's at the "boundary", ie it connects the repo to the cloud CI. Note that Scorecard does not yet support other CI platforms, and I'm not sure what our plans are for it. I think it'd be nice to have but the conversation seems similar. Where does Scorecard stop?

@ossf/scorecard-maintainers what are your thoughts?

[raghavkaul]

I think this is a bit too AWS-y to be in scope for Scorecard. It's not really about GitHub Actions CI or another CI, but about scanning AWS IAM role trust relationships. We'd add a bunch of dependencies on AWS SDK and in general developers would be better suited scanning AWS IAM holistically than running scorecard. There's also all sorts of things like SCPs, permission boundaries, etc. that could come into play with AWS IAM and I'm skeptical that scorecard can do that best.

[laurentsimon]

Note that the same problem exists in GCB and Azure.

[laurentsimon]

Here's the GCB example , I think that's the blog post https://ermetic.com/blog/gcp/how-attackers-can-exploit-gcps-multicloud-workload-solution/

[raghavkaul]

To clarify, my issue isn't that it's AWS-specific but that it's related to fixing the IAM / ACL settings which are a big lift. It's not directly related to changing CI settings or GitHub config.

Remediation is hard b/c effective IAM rules are the confluence of multiple overlapping rules. What if the IAM role is re-used between other services? We couldn't recommend some easy remediation like updating the role policy because it'd affect other services. What if there's a permission boundary that prevents the vulnerability? Then scorecard would have raised a false positive.

I'm not against Scorecard ever doing this, but the IAM scanning feels daunting and potentially noisy. If Tinder's tool were written in Golang, or there was another tool in Golang, that would made me confident that the cloud detection would be an easy port, but it's written in Python.

[laurentsimon]

I think we should not think about implementation details just yet. The first question to answer is whether our users would like Scorecard to be able to detect this, ie does the feature make sense product-wise? It's similar to the Webhook check to some extent, ie it's about how you connect your GitHub repo with your "external" CI components. These are highly-critical bugs (like Webhook and Dangerous Workflows)

Implementation-wise, I have not thought about it yet... I was mostly thinking about the question above. It may be possible to look for usage of https://github.com/google-github-actions/auth in workflows, and then query the settings for that particular service accounts. Again, I may be way off. I think we should answer the product question first. Even if it makes sense product-wise, we don't need to implement the feature if there are blockers implementation-wise.

[github-actions]

This issue is stale because it has been open for 60 days with no activity.