The lack of Python requirements.txt support is a bit odd, since it's conceptually quite similar to the two supported mechanisms.
That allows you to run a check for vulnerable packages before each commit and via CI.
[0] https://docs.pipenv.org/advanced.html#detection-of-security-...
https://python-packaging.readthedocs.io/en/latest/dependenci...
Example: https://github.com/HearthSim/python-hslog/blob/master/setup....
Altho you can write to one of the other formats or read from it - you'd have to tell the scanner what the true build source is
[0] https://github.com/kennethreitz/pipenv/blob/master/Pipfile
[0] https://docs.pipenv.org/advanced.html#detection-of-security-...
I hope they go with Pipfile/Pipfile.lock [0] and pipenv [1] rigth away!
I don't see that happening.
If people get value from it, editing a simple text file once or twice a year wouldn't be difficult.
A text file that just declares that "this project uses lib 2.1". It isn't a part of the build system in any way.
That would be awesome.
Option 1: Adding feature to npm/composer/gem/pip ad infinitum
Option 2: add per-language parser support to the alerting tool instead.
Option 2 doesn't necessitate a new (information-duplicating, still potentially error prone) standard, and can likely leverage available, tested libraries ;-)
* any non Javascript / ruby / go languages don't have standard packages, package names, etc.
* any non Javascript / ruby / go languages may be using one of many build systems. It's just too hard to troll through random build systems to see what dependencies are used
* therefore, a simple text file is what will work, and is what will be trivial for everyone to use
* if you find it too hard to update one line in a text file when you add (for example) a new dependency on libldap... you shouldn't be programming
Would have thought Maven popularized standard package names and build dependency (POM) files.