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

Customization of results #729

Open
4 tasks
laurentsimon opened this issue Jul 7, 2022 · 21 comments
Open
4 tasks

Customization of results #729

laurentsimon opened this issue Jul 7, 2022 · 21 comments

Comments

@laurentsimon
Copy link
Contributor

laurentsimon commented Jul 7, 2022

Some ideas

@laurentsimon
Copy link
Contributor Author

/cc @raghavkaul

@naveensrinivasan
Copy link
Member

This should be more of a config option. But isn't this supposed to be in Scorecard rather than action? That way it is consistent and Scorecard action is just another way to run scorecard.

@laurentsimon
Copy link
Contributor Author

laurentsimon commented Jul 8, 2022

The Scorecard Action can build a policy on top of the results, in which case this feature need / should not be in Scorecard, especially if we don't want to enforce / support a universal policy style / language / framework. That's what I had in mind. This keeps the Scorecard results "universal", same as the cron results. The policy could be applied on top of cron results, for example, using whatever logic the consumer wants.

Wdut?

@azeemshaikh38
Copy link
Contributor

Another customization to consider is improving Wont Fix behavior for Scorecard checks. see github/codeql-action#986 (comment).

@laurentsimon
Copy link
Contributor Author

yes, that's the 143 issue above. I'll update the description. Thanks

@azeemshaikh38
Copy link
Contributor

yes, that's the 143 issue above. I'll update the description. Thanks

Ah sorry, didn't see it. My bad.

@naveensrinivasan
Copy link
Member

The Scorecard Action can build a policy on top of the results, in which case this feature need / should not be in Scorecard, especially if we don't want to enforce / support a universal policy style / language / framework. That's what I had in mind. This keeps the Scorecard results "universal", same as the cron results. The policy could be applied on top of cron results, for example, using whatever logic the consumer wants.

Wdut?

Can you please unpack what you mean with an example? For example, I envisioned that end-users can apply a policy on top scorecard results to fit their needs.

For example

  1. Score Customization for a given repository and a given check
  2. Ignoring certain checks from certain folders.

@laurentsimon
Copy link
Contributor Author

pretty much what you said. Not sure that score customization is useful if we have more structured input, but maybe.

They could also customize the criticality of results, or ignore certain "details" using the detailID field suggested in ossf/scorecard#1874 (comment)

Let me know if this is a bit clearer or not. Thanks for asking

@naveensrinivasan
Copy link
Member

pretty much what you said. Not sure that score customization is useful if we have more structured input, but maybe.

They could also customize the criticality of results, or ignore certain "details" using the detailID field suggested in ossf/scorecard#1874 (comment)

Let me know if this is a bit clearer or not. Thanks for asking

Yes, it is! Thanks. Then why not have this functionality in Scorecard versus here. That is what I don't understand.

@laurentsimon
Copy link
Contributor Author

Thanks @naveensrinivasan for pushing on this.

Initially I thought we would not want to commit to a particular policy format in the main scorecard repo, and let consumers decide how they want to handle it. You're making a good point that we could support a simple policy format in the main scorecard repo, and it would benefit everyone. So I think I'm fine with that.

@azeemshaikh38 any further thought about this?

@laurentsimon
Copy link
Contributor Author

fyi, here's a possible policy file:

Version: X
BasePolicy: BuiltInAllChecksEnforced | BuiltInAllChecksEnforced | __path_to_file__
IgnoredPaths:
IgnoredFiles:
EnforcedPaths:
EnforcedFiles:
Checks:
  - CheckName:
    - Status: enforced | ignored
    - Criticality: XXX
    - IgnoredPaths:
      - a_path_
      - a/**/path
    - IgnoredFiles:
      - a_file
      - another_file
    - EnforcedPaths:
     ...
    - EnforcedFiles:
    ...
    - Rules:
      # RuleName is the same as `DetailID` in https://github.com/ossf/scorecard/issues/1874#issuecomment-1178259870
      - RuleName: 
         - Status: enforced | ignored
         - Criticality: XXX
         - IgnoredPaths:
         - IgnoredFiles:
         - EnforcedPaths:
         - EnforcedFiles:

@naveensrinivasan
Copy link
Member

The community is leaning towards OPA https://github.com/open-policy-agent/opa.

@laurentsimon
Copy link
Contributor Author

laurentsimon commented Jul 12, 2022

Yes. Kind of why I suggested earlier to have something simple only in the Action and not commit to something complex / to main in the main CLI as well.

I have not looked into OPA or the complexity for both us or the user. I think a simple solution first would help users and would not require them to learn a new programming language. AllStar takes this approach and is able to express many policies this way.

Later we can provide template OPA policy (I think we discussed this a few months ago but did not have bandwidth to look more closely).

Wdut?

@naveensrinivasan
Copy link
Member

That would be breaking a change in Policy.
Scorecard should avoid breaking changes and we would have to support both of them.
We should rather do it right that is my opinion. Is there a rush for this feature?

If I am not wrong @developer-guy was working on cosign with OPA.

@laurentsimon
Copy link
Contributor Author

That would be breaking a change in Policy. Scorecard should avoid breaking changes and we would have to support both of them. Is there a rush for this feature?

A lot of people want ways to opt out. Having a simple policy and actually delivering it seems like a good step forward to me. It's not always viable to do everything at once, and iterations are always necessary. We don't even know what other policies would want, so betting on OPA seems overkill.

@naveensrinivasan
Copy link
Member

We should have some to measure lot of people want ways to opt out

This should be a discussion topic for bi-weekly

@laurentsimon
Copy link
Contributor Author

I went thru the issues last week and found 3-4 issues of people asking for customization like this. It's also something people have been complaining about in conversations.

@naveensrinivasan
Copy link
Member

OK, Go ahead if you have heard from people in conversations 👍 . I just wanted to be sure that we are building what customers want. Thanks for the explanation!

@laurentsimon
Copy link
Contributor Author

laurentsimon commented Jul 12, 2022

I'd rather hear from more people, and also talk about it in the bi-weekly as you mentioned. Was just trying to say there's demand, but I agree with you on discussing it to decide on prioritization.

Thanks again for all the questions you asked

@laurentsimon
Copy link
Contributor Author

laurentsimon commented Jul 19, 2022

/cc @ethanent @jeffmendoza may be relevant to the work on AllStar policies for Scorecard.

@jonasbb
Copy link
Contributor

jonasbb commented Jul 20, 2022

I requested a way to silence reports in #143. In that case, I want to relax the requirements for CI code. Not all code needs to uphold the same quality measures, mainly test code and CI code. The proposed policy file would work for me. It would allow suppressing the Pinned-Dependency check for the GitHub Actions code, while keeping it for the rest. It also looks flexible enough to further differentiate between different projects in the same repo or other parts.

In the proposed policy file, there are both IgnoredPaths and IgnoredFiles. This seems somewhat redundant and a single option might work, similar to the syntax of gitignore files.

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

4 participants