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

Parts of security scorecard doesn't allow excluding issues from scoring when they have no affect on an end-user #4036

Open
yrusskih opened this issue Apr 15, 2024 · 3 comments
Labels
kind/bug Something isn't working

Comments

@yrusskih
Copy link

Describe the bug
We have a low security score at https://securityscorecards.dev/viewer/?uri=github.com/JetBrains/intellij-community for Binary-Artifacts and Pinned-Dependencies categories although most of the listed paths are from ../testData/.. directories thus can't influence .

Reproduction steps
Steps to reproduce the behavior:

  1. Expand Binary-Artifacts section.
  2. Check paths to the files - most of them are in testData folders which doesn't affect a distribution or an end-user.
  3. Expand Pinned-Dependencies section.
  4. Check paths to the files - most of them are in testData folders which doesn't affect a distribution or an end-user.
  5. Expand Vulnerabilities section.
  6. Check paths to files caused Vulnerabilities findings - most of them are in testData folders which affects neither a distribution nor an end-user. Also most of them are related to Python dependencies although the product itself is predominantly written in Java and Python code is used there for tests.

Expected behavior
There is a way either to exclude paths not affecting an end-user or a product's distribution from the analysis, or to exclude them from scoring so a reader could see issues with a vendor's comment but in a muted form, to have a score reflecting security of an end-user product. Currently, it indicates security of files included in a repo which may have lax connection to security of a final artifact.

@yrusskih yrusskih added the kind/bug Something isn't working label Apr 15, 2024
@spencerschrock
Copy link
Contributor

spencerschrock commented Apr 15, 2024

Being able to declare testdata directories (along with other annotations) is something we're currently working on with maintainer annotations (Duplicate of #1907), so stay tuned.

You can see part of this in an open PR (#3905)

const (
// TestData is to annotate when a check or probe is targeting a danger
// in files or code snippets only used for test or example purposes.
TestData Reason = "test-data"

@yrusskih
Copy link
Author

@spencerschrock thank yoy for sharing! I've subscribed to the PR.

What's your forecast on the timeline of having this feature available for us?

@spencerschrock
Copy link
Contributor

It is one of our items currently being worked on, but I don't have a great timeline, especially when seeing the results in our API.

Note: we currently exclude testdata directories (which is the Go naming convention for test data directories), but our comparison is case-sensitive. Seeing as your directory is named testData, it may be a simpler fix to use a case-insensitive comparison which would ignore your testData directory regardless of the maintainer annotation feature status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
Status: No status
Development

No branches or pull requests

2 participants