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

Artifact Pulled event data model changes to registries #144

Closed
afrittoli opened this issue Jun 19, 2023 · 4 comments
Closed

Artifact Pulled event data model changes to registries #144

afrittoli opened this issue Jun 19, 2023 · 4 comments
Labels
roadmap Items on the roadmap
Milestone

Comments

@afrittoli
Copy link
Contributor

afrittoli commented Jun 19, 2023

We may need to add to the artifact.pulled event we have today to facilitate the CDEvents adoption by Harbor and other registries - see goharbor/community#229 from more details.

@afrittoli afrittoli added the roadmap Items on the roadmap label Jun 19, 2023
@afrittoli afrittoli added this to the v0.4 milestone Jun 19, 2023
@afrittoli afrittoli changed the title Artifact Pushed event data model changes to registries Artifact Pulled event data model changes to registries Nov 26, 2023
@mekhanique
Copy link

Suggest using artifact.quarantined rather than artifact.pulled; quarantined makes clearer that it was related to a security issue IMO.

@afrittoli
Copy link
Contributor Author

Thanks @mekhanique, the artifact.pulled event is meant to track artifact download events (so a counterpart of the artifac pushed event).
We could add a quarantine event too if that's something registries implement.

@mekhanique
Copy link

mekhanique commented Dec 5, 2023

Well, those aren't the same then :-). I'd suggest artifact.downloaded over artifact.pulled in that case; the name is more self explanatory this way.

Re: artifact.quarantined -- Yes, we quarantine malicious versions of dependencies. Having the event allows for a history around the version to be kept (in an event store for records purposes). Leaving the artifact in a local non-resolvable repository also helps to provide further information around downloads, etc. This is highly useful in regulated environments such as med tech. There are a few ways one can "implement" a quarantine system w/ a repository system, but it's not a "first class feature". Some folks use Bytesafe, JFrog Curation as a front end, but naturally those services cost money. A simple (and free-ish) way of doing this is to create a local resolvable repository to which you post a bogus artifact with the same coordinates as the malicious artifact. You then ensure that this local repository is ahead of your remote repo in your resolution order for your virtual repository (i.e. the repo everyone actually resolves things from). This, of course, presumes you're running a local repository service; such as Artifactory, Nexus or the like. It also requires a tool such as Dependency Track or its ilk to create events upon which an action can be based to perform this quarantine process.

I'd like to further point out an approach that I think makes a lot of sense; making auditing a first class citizen. All highly regulated and security concious environments require heavy event logging. Ensuring that all designs take this into account will be of great benefit to users.

@e-backmark-ericsson
Copy link
Contributor

Closed as finished, while some remainders will be handled in #195

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
roadmap Items on the roadmap
Projects
None yet
Development

No branches or pull requests

3 participants