Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

Vulnerability scanning improvements #1658

Closed
Vad1mo opened this issue Feb 5, 2018 · 5 comments
Closed

Vulnerability scanning improvements #1658

Vad1mo opened this issue Feb 5, 2018 · 5 comments

Comments

@Vad1mo
Copy link
Contributor

Vad1mo commented Feb 5, 2018

This Issue is summary about what I think should be improved with the vulnerability scanning functionality in the upcoming releases:

  1. Vulnerability should have their own tables.
    This opens the option to add more functionality like whitelisting, todo, notification and ignore.

  2. Rescheduling of scanning,
    Scanning should not only happen after pushing. Images should be scanned on a regular basis.

  3. Better Vulnerability overview and reporting.
    See which images are vulnerabel.

  4. Add vulnerability results to audit trail

@Vad1mo Vad1mo changed the title Improve vulnerability scanning Vulnerability scanning improvements Feb 5, 2018
@mssola
Copy link
Collaborator

mssola commented Feb 6, 2018

This opens the option to add more functionality like whitelisting, todo, notification and ignore.

Do you have something specifically in mind (e.g. use case, workflow) ?

Rescheduling of scanning. Scanning should not only happen after pushing. Images should be scanned on a regular basis.

Makes sense. Note though that these are two different features:

  1. Allow users to manually re-schedule scanning.
  2. Regularly scan even if all tags are marked as scanned.

Better Vulnerability overview and reporting

Yeah, totally. Maybe on the repositories#index page ?

Add vulnerability results to audit trail

👍 And maybe add a permanent link somewhere in the likes of "You have vulnerable images! See for more info"

mssola added a commit to mssola/Portus that referenced this issue Feb 8, 2018
This commit adds two new endpoints: `/vulnerabilities` and
`/vulnerabilities/:id`. Both these endpoints require admin privileges,
and they will simply toggle the `scanned` column of tags so the scanning
task can pick them up.

This commit does not deal with the UI part, it simply provides the
backend code. The frontend code can be delivered later on.

See SUSE#1658

Signed-off-by: Miquel Sabaté Solà <[email protected]>
termdew pushed a commit to termdew/Portus that referenced this issue Feb 12, 2018
This commit adds two new endpoints: `/vulnerabilities` and
`/vulnerabilities/:id`. Both these endpoints require admin privileges,
and they will simply toggle the `scanned` column of tags so the scanning
task can pick them up.

This commit does not deal with the UI part, it simply provides the
backend code. The frontend code can be delivered later on.

See SUSE#1658

Signed-off-by: Miquel Sabaté Solà <[email protected]>
@potzkovge
Copy link

potzkovge commented Mar 29, 2018

Do you have a timeline for these features?

Without knowing the exact details how clair rescans known layers due to new CVEs, another approach may be to let portus be notified by clair via webhooks. With this periodical scans may not be necessary.

@mssola
Copy link
Collaborator

mssola commented Apr 5, 2018

Do you have a timeline for these features?

Some of the things discussed here live in separate issues which are going to be handled either in 2.4 or 2.5 (e.g. #1669). Some others have not been planned, but maybe when we release 2.4 in June we can re-visit what we planned for 2.5.

Without knowing the exact details how clair rescans known layers due to new CVEs, another approach may be to let portus be notified by clair via webhooks. With this periodical scans may not be necessary.

That was also pointed out on another issue, and it makes total sense. Thanks for the feedback 👍

@Vad1mo
Copy link
Contributor Author

Vad1mo commented Apr 5, 2018

I was planning to outline how to improve the vulnerability scanner.

  • usability
  • features

with the idea to derive better and automated conclusions out of the results.
I think its utopic to have everything in 2.5 however we can slowly move into that direction. where we can already start with in 2.4.

Especially we need to define a proper vulnerability model with own tables, then anyone can create contribution like reports, notification, audit, quality gates, APIs and so forth.

@Vad1mo
Copy link
Contributor Author

Vad1mo commented Apr 5, 2018

I would like to close this issue. I created #1761 so we can track the progress and gather further requirements regarding the possible improvements.

@Vad1mo Vad1mo closed this as completed Apr 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants