Personally, I think vulnerable packages could be retained locally and was
subscribable. Dealing with it during a build would be a local operation.
Here's a repo of all Maven Meta data (I wrote some stuff in Python and
Herve redid it in Java) -> https://github.com/hboutemy/mcmm-yaml/
While vulnera
on the "better education" journey, I started by adding OWASP Dependency Check
to our list of remarkable third party projects that provide a Maven plugin
http://maven.apache.org/plugins/index.html#Misc
Don't hesitate to provide little patches for other documentation improvements
Regards,
Herv
Hi,
A few thoughts:
- there are more than 2 repository providers:
http://maven.apache.org/repository-management.html
- issuing a warning only when *downloading* content that has a CVE IMHO won't
really be efficient, given there is a local cache: if you miss the warning at
first download, you'l
Hi, Chas,
thanks for answering, absolutely! I see this as a comprehensive approach
which cannot be done on just one side:
- IETF to define a new header X-something or even HTTP response code
standard i.e. "460 - Content generally known to be insecure"
- Repository providers to implement issuing th
If you want the package repository to add the header, you will need to make
your request to Sonatype (Nexus) and JFrog (Artifactory)
Chas
> On Mar 6, 2018, at 4:12 AM, Peter Muryshkin wrote:
>
> Hi, all,
>
> currently you can run OWASP dependency check plugin against your projects.
>
> Thoug
Hi, all,
currently you can run OWASP dependency check plugin against your projects.
Though, this seems to make security more or less optional: unaware either
lightheaded teams could miss this.
What if a package repository would integrate with this dependency checking
and issue a warning, say a s
