You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am seeing CVE's reported by safety check in stock Debian and Ubuntu environments, even in the latest official Docker images. For comparison, safety reports zero vulnerabilities for the latest stock Fedora Docker image.
I contacted the Ubuntu team via Launchpad, but they are pushing back claiming that all OS distribution Python packages regularly receive security backports.
When an engineer uses an out-of-OS-distribution package manager such as ASDF, virtualenv, etc., then they have more options for simply upgrading past vulnerabilities. However, packages installed by the OS distribution package manager tend to lag far behind. It's reasonable to assume that out-of-OS-distribution packages have relatively straightforward version to CVE presence/absence mappings. Whereas OS distribution packages may include backports that the safety CVE Web pages do not appear to document.
When I visit the safety CVE page for a pip vulnerability, for example, I do not see an indication of which OS distributions, if any, include security patches that address the vulnerability.
Can you please clarify whether the safety SAC tool integrates with OS distribution package security backport data?
Which operating systems and which package managers are supported? macOS, Windows, Linux distributions, various UNIX distributions, etc.
For example, macOS engineers often use softwareupdate (OS distribution level), but may also use Homebrew, MacPorts, or Fink (outside of OS distribution). BSD's have port, pkgsrc, and pkgin.
Which version managers (also outside of OS distribution) are supported? We have dozens online, including ASDF, virtualenv, rvm, gvm, nodenv, nodeenv, and sdkman, just to name a few.
Can safety currently distinguish between packages installed by the operating system versus out-of-OS-distribution package managers?
If only a single CVE were ever the problem, then it would be easy enough to configure that as an excluded security finding. However, I maintain portable software applications designed to support hundreds of different environment combinations. As a safety user, I don't find it scalable to manually check every finding against every possible environment for backporting details. That's something the computer should be able to automate. The noise of spurious SAC reports can unfortunately take away valuable engineering time.
The text was updated successfully, but these errors were encountered:
Thank you for bringing this issue to our attention and for your patience.
After consideration, we've decided to move this issue to the "wontfix" category for now. We wanted to provide some context for this decision:
Current Capabilities: Currently, Safety is not structurally designed to handle the integration of OS distribution package security backport data. We recognize the complexity and the importance of this feature for users managing diverse environments.
Future Plans: While this is a valuable enhancement, it's not part of our immediate development plans. We aim to revisit and potentially address this in the future, but it might take around 1-2 years to prioritize and implement such a significant change.
We understand the challenges you face with maintaining portable software across various environments and the impact of spurious reports. We appreciate your understanding and assure you that we will keep this on our radar for future improvements.
Thank you again for your contributions and feedback. If you have any further suggestions or reports, we'd love to hear from you!
Hi,
I am seeing CVE's reported by
safety check
in stock Debian and Ubuntu environments, even in the latest official Docker images. For comparison, safety reports zero vulnerabilities for the latest stock Fedora Docker image.I contacted the Ubuntu team via Launchpad, but they are pushing back claiming that all OS distribution Python packages regularly receive security backports.
When an engineer uses an out-of-OS-distribution package manager such as ASDF, virtualenv, etc., then they have more options for simply upgrading past vulnerabilities. However, packages installed by the OS distribution package manager tend to lag far behind. It's reasonable to assume that out-of-OS-distribution packages have relatively straightforward version to CVE presence/absence mappings. Whereas OS distribution packages may include backports that the safety CVE Web pages do not appear to document.
When I visit the safety CVE page for a pip vulnerability, for example, I do not see an indication of which OS distributions, if any, include security patches that address the vulnerability.
https://data.safetycli.com/v/62044/f17/
Can you please clarify whether the safety SAC tool integrates with OS distribution package security backport data?
Which operating systems and which package managers are supported? macOS, Windows, Linux distributions, various UNIX distributions, etc.
For example, macOS engineers often use
softwareupdate
(OS distribution level), but may also use Homebrew, MacPorts, or Fink (outside of OS distribution). BSD's have port, pkgsrc, and pkgin.Which version managers (also outside of OS distribution) are supported? We have dozens online, including ASDF, virtualenv, rvm, gvm, nodenv, nodeenv, and sdkman, just to name a few.
Can safety currently distinguish between packages installed by the operating system versus out-of-OS-distribution package managers?
If only a single CVE were ever the problem, then it would be easy enough to configure that as an excluded security finding. However, I maintain portable software applications designed to support hundreds of different environment combinations. As a safety user, I don't find it scalable to manually check every finding against every possible environment for backporting details. That's something the computer should be able to automate. The noise of spurious SAC reports can unfortunately take away valuable engineering time.
The text was updated successfully, but these errors were encountered: