Add Packagist security advisories parser

[Szasza]

The Current Behaviour section assumes that #796 is already merged.

Current Behaviour:

When a BOM is parsed which contains Composer-type packages, there is no check if there is a reported vulnerability for the given package versions in Packagist.

Proposed Behaviour:

As per https://packagist.org/apidoc#list-security-advisories (bottom of the page) Packagist exposes an API endpoint which could be used to check if there are any security advisories for the packages in the BOM. This API could be utilised similarly to the NPM audit advisories which is already implemented. The difference to NPM is that specific package names need to be used with Packagist, so the security advisories would only be pulled when a BOM/dependency is added.

Additional note:

This is already being implemented but a PR will only be opened when #796 actually gets merged.

[stevespringett]

DT should use OSS Index (if enabled) for the analysis of PHP Composer components. I said should because I've never actually tested it. But the logic is that if a component has a PURL, the component will be analyzed with OSS Index.

But agree, this would be a nice enhancement to have.

Let's target all the PHP enhancements for 4.1.

[Szasza]

@stevespringett thank you for the information, it is much appreciated. I will check if the OSS Index is used for Composer components.

[nscuro]

@Szasza @stevespringett It is, my org already had a few findings pop up in the past. It would be interesting to know though if OSS Index already includes the advisories from packagist.

[stevespringett]

Good. Yes, regardless, I think having more analyzers is a good thing as it gives the community choice and reduces the reliance on a single source.

[stevespringett]

Moving this out from 4.1. Will target a future release.

One issue I see with supporting Packagist advisories is they all lack severity. If the advisory contains a CVE, the severity can be retrieved from that, but if the advisory doesn't contain a CVE, severity will be unknown.

[jnkowa-gfk]

really love to see this feature.

example: currently seeing a lot of issues with https://packagist.org/packages/typo3/cms-core
but DependencyTrack does not show the issue, though an affected version of typo3/cms-core is listed.

Security API: https://packagist.org/api/security-advisories/?packages[]=typo3/cms-core

[jkowalleck]

Hello @Szasza ,

you wrote

This is already being implemented but a PR will only be opened when #796 actually gets merged.

#796 was merged.

Did I understand you right, that the code for this very issue was created, but the PR is not opened, yet?
Could you have a PR opened and linked to #798?

appreciate your work very much.

If SBOM generated by cyclonedx-php-composer needs to include additional information, feel free to reach out to me or open an issue for cyclonedx-php-composer,
As a maintainer of cyclonedx-php-composer i will be happy to have it sorted out and implemented ASAP. :-)

[jkowalleck]

@stevespringett wrote in #798 (comment)

One issue I see with supporting Packagist advisories is they all lack severity. If the advisory contains a CVE, the severity can be retrieved from that, but if the advisory doesn't contain a CVE, severity will be unknown.

Questions:

• How does the existence of a CVE affect DependencyTrack's UI/UX?
• Does an advisory without CVE fall back to a default level, and which level would this be?

---

example for CVE in API response

• existing : https://packagist.org/api/security-advisories/?packages[]=symfony/symfony
• missing : https://packagist.org/api/security-advisories/?packages[]=typo3/cms-core

[stevespringett]

DT supports severity of critical, high, medium, low, info, and unassigned. Since Packagist advisories do not support severity, then for advisories with a CVE the severity can be derived from the CVE. For advisories without a CVE, the severity will be unassigned.

Unassigned severity has the same risk score as high severity.

The UI will not be impacted. It already supports unassigned severity.

[jkowalleck]

Hello @stevespringett,

any updates on this feature?
I assume not, since the situation with the data source seams to be unchanged.

[tsfoer]

Any updates on this?

[jkowalleck]

@Szasza could you add a PR for this?
#796 was merged and you mentioned to have code ready, that required this merge.

[jkowalleck]

feature request: Strip v version prefix for packagist Index analysis (like #1220)

background & examples:
see also: CycloneDX/cyclonedx-php-composer#102
see package typo3/cms-core for example.

• on the website it is prefixed with a v
• composer internally also uses the v prefix - see any of composer`s lock files for example.
• BUT: in the response of https://packagist.org/api/security-advisories/?packages[]=typo3/cms-core the affectedVersions does not have a v prefix.

conclusion: the implementation should strip the v. dont rely on any SBoM sources to have the v stripped already.

[JorisVanEijden]

• BUT: in the response of https://packagist.org/api/security-advisories/?packages[]=typo3/cms-core the affectedVersions does not have a v prefix.

conclusion: the implementation should strip the v. dont rely on any SBoM sources to have the v stripped already.

The "affectedVersions" returned from that API is not a list of versions but a "composer constraint".
To see if a version from an SBOM is vulnerable you have to perform the same composer matching logic.
see https://github.com/composer/semver/blob/main/src/Semver.php