RE: https://github.com/CycloneDX/cyclonedx-php-composer/pull/10#issuecomment-774524762

this is a messy branch, but i think its worth to take a look. basically Work In Progress.

highlights:

• more CI chain
• a demo in CI chain
• more QA tools
• more structured tests (work in progress)
• new: deserializer is implemented and showcased in the functional tests
• (de)serializer still handcrafted.

:construction: my person todo-list to get from WIP to ready state: https://github.com/jkowalleck/cyclonedx-php-composer/issues/2

:information_source: STATUS

• lots of the QA features of this PR were merged into master in separate small chunks already.
• the demo similar to the one of this rework was merged into master lately (see #58)
• core rework/refactoring is still unfinished
• --> parts f this PR are unnecessary now, since they were integrated into master already.
• --> this PR will be closed soon, and more recent and rebased version will be opened as a draft, then.

• the version you are using cyclonedx/cyclonedx-php-composer V3.9.0

• your operating system and version WSL2.0 Ubuntu 20.04 on Windows 10

• reproducible steps (1 2 3...) that cause the issue including any required files Execute "php composer.phar make-bom --exclude-dev --output-file=composer-bom.xml ./composer.json"

• what you expected, versus what happened The system generates an composer-bom.xml file, but instead the system gives an error. See error and reason below

• any relevant screenshots and other outputs Output:

Validate BOM with CycloneDX\Core\Validation\Validators\XmlValidator for 1.3
ValidationError:
ValidationError: Element '{http://cyclonedx.org/schema/bom/1.3}url': '**http://pear.php.net/bugs/search.php?cmd=display&package_name[]=PEAR_Exception**' is not a valid value of the atomic type 'xs:anyURI'.

the drush/drush requirements tree has pear/pear_exception as an requirement. Inside the composer.json of this module there is an URL with [] (See support->issues in the content below)

the systems fails validating the output with the following message:

Validate BOM with CycloneDX\Core\Validation\Validators\XmlValidator for 1.3 ValidationError: ValidationError: Element '{http://cyclonedx.org/schema/bom/1.3}url': 'http://pear.php.net/bugs/search.php?cmd=display&package_name[]=PEAR_Exception' is not a valid value of the atomic type 'xs:anyURI'.

Generating the same file with --no-validate generates the file correctly, which we merge with our NPM bom file and upload to dTrack

{
            "name": "pear/pear_exception",
            "version": "v1.0.1",
            "source": {
                "type": "git",
                "url": "https://github.com/pear/PEAR_Exception.git",
                "reference": "dbb42a5a0e45f3adcf99babfb2a1ba77b8ac36a7"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/pear/PEAR_Exception/zipball/dbb42a5a0e45f3adcf99babfb2a1ba77b8ac36a7",
                "reference": "dbb42a5a0e45f3adcf99babfb2a1ba77b8ac36a7",
                "shasum": ""
            },
            "require": {
                "php": ">=4.4.0"
            },
            "require-dev": {
                "phpunit/phpunit": "*"
            },
            "type": "class",
            "extra": {
                "branch-alias": {
                    "dev-master": "1.0.x-dev"
                }
            },
            "autoload": {
                "classmap": [
                    "PEAR/"
                ]
            },
            "notification-url": "https://packagist.org/downloads/",
            "include-path": [
                "."
            ],
            "license": [
                "BSD-2-Clause"
            ],
            "authors": [
                {
                    "name": "Helgi Thormar",
                    "email": "[email protected]"
                },
                {
                    "name": "Greg Beaver",
                    "email": "[email protected]"
                }
            ],
            "description": "The PEAR Exception base class.",
            "homepage": "https://github.com/pear/PEAR_Exception",
            "keywords": [
                "exception"
            ],
            "support": {
                "issues": "**http://pear.php.net/bugs/search.php?cmd=display&package_name[]=PEAR_Exception**",
                "source": "https://github.com/pear/PEAR_Exception"
            },
            "time": "2019-12-10T10:24:42+00:00"
        }

backgroud

in php/composer the v prefix in versions is understood by the ecosystem. it "heals" itself regarding a missing/existing v. in the lock file the actual version is used; the v is added/removed to match the correct prefix of the actual version. (example)

i would prefer to keep the v if composer found that it is part of the actual version.

but unfortunately this would be a change of the implementation since v1 that is actually kept until now(v3) since it seams to be there for a reason (, which drives me mad since the actual version sometimes has a v for real).

proposal

dont handle a leading v in any special way. just leave everything as is. additionally: make it optional(opt-in) to strip the v in front of a version. (only if there is an actual need for this, dont write this feature unless it is required)

impact

this would be a breaking change, since current implementation strips the v per default. Proposed change would remove this behavior per default.

acceptance criteria

• [ ] the v is not stripped, if composer tells that it exists.
• [ ] remove --no-version-normalization option and related capabilities
• [ ] remove the "normalizer" entirely

work packages

tbd

there is a repo https://github.com/CycloneDX/sbom-examples it hosts example output of this project as https://github.com/CycloneDX/sbom-examples/tree/master/laravel-7.12.0

there s a demo project for cyclonedx-php-composer: https://github.com/CycloneDX/cyclonedx-php-composer/tree/master/demo

goal: stream line both of them:

• [x] adjust cyclonedx-php-composer's demo to produce the results for https://github.com/CycloneDX/sbom-examples/tree/master/laravel-7.12.0
  • might not be done completely correct. see discussion in this issue below
• [x] link with https://github.com/CycloneDX/sbom-examples/tree/master/laravel-7.12.0
• [x] update https://github.com/CycloneDX/sbom-examples/tree/master/laravel-7.12.0
  • update XML
  • add JSON
  • cross-link cyclonedx-php-composer's demo with https://github.com/CycloneDX/sbom-examples/tree/master/laravel-7.12.0
  • :100: PR: https://github.com/CycloneDX/sbom-examples/pull/8
• [x] dependabot must ignore demo dir
• [x] reproducible tests check that SBOM output for XML files did not change
• [x] reproducible tests check that SBOM output for JSON files did not change

demo project and reproducible outcome is available here: https://github.com/CycloneDX/cyclonedx-php-composer/tree/master/demo/laravel-7.12.0

the current implementation has the change to create invalid XML: when a dependency uses a license that is unknown to the XML schema.

licenses are values of an enumeration described here: https://cyclonedx.org/schema/spdx according to XML schema.

this patch does the following:

• add tests for licenses that are invalid.
• ship a list of known licenses.
• licenses in the XML will be written as <id> or <name> - just as described in the XML schema.
• add a script to download latest known licenses.

As per https://github.com/package-url/purl-spec a package URL is as follows:

scheme:type/namespace/name@version?qualifiers#subpath

This package generates URLs such as pkg://composer/... which don't follow the specification, the // part needs to be removed.

Updates the requirements on ergebnis/composer-normalize to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This PR adds an initial implementation of the CycloneDX Composer plugin. It is capable of generating valid CycloneDX v1.1 BOMs from Composer's lockfile.

My knowledge of the PHP ecosystem is kind of limited, so I expect some bugs to surface once this plugin experiences higher usage counts.

@stevespringett: In case you'll merge this, you need to setup a Packagist account as described here.

Updates the requirements on vimeo/psalm to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Is your feature request related to a problem? Please describe.

no

Describe the solution you'd like

have the composer package's authors in the SBOM result for each component and the metadata.component

Describe alternatives you've considered

none

Additional context

Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.

OWASP's Dependency track internal analyser uses only CPE (not PURL) to match components with NVD vulnerabilities. The current version of this package does not seem to include CPE in the generated BOM file When uploaded to dependency track, the default analyser fails to match any php dependency to known vulnerabilities.

Describe the solution you'd like

In the generated bom in cyclonedx format, include the CPE of all packages

Describe alternatives you've considered

Dependency track can be configured to user other scanners, which can handle the provided packages PURLs But it would be better to be able to benefit also from the https://nvd.nist.gov/vuln

Packagist is also integrating nist's NVDs, but having all the information centralised in the dependency track application would be great

Additional context

With the example of https://nvd.nist.gov/vuln/detail/CVE-2021-3603 the expected CPE is cpe:2.3:a:phpmailer_project:phpmailer:*:*:*:*:*:*:*:* ( |<=6.4.1 )

Looking at the composer.json file, there's no mention of phpmailer_project, neither on packagist's page https://packagist.org/packages/phpmailer/phpmailer#v5.2.26 I don't know how it should be built with the available composer's data...?

Updates the requirements on vimeo/psalm to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

• [ ] require cyclonedx/cyclonedx-library:^2.0 (no more 2.x-dev) - #128
• [x] have the used property taxonomy merged - https://github.com/CycloneDX/cyclonedx-property-taxonomy/pull/37
• [ ] TO BE CONTINUED
• [ ] finish all in https://github.com/CycloneDX/cyclonedx-php-composer/milestone/5

TODO

• [ ] find lowest boundaries, after implementation is done, so that the lowest reasonable versions of composer-api and dependencies can be specified
• [x] have a proper reimplementation -
  • [x] basics see #254
  • [x] metadata.tool
  • [x] see the demo data results and how they differ !
  • [x] omit plugins
• [x] reproducible output - or add creation date etc ...
• [ ] have all planned features implemented: https://github.com/CycloneDX/cyclonedx-php-composer/milestone/5
• [ ] have reasonable tests - besides the demos that are integration-test-like
• [ ] update the docs
• [ ] update the changelog
• [ ] pin the used version of the CDX php lib

Is your feature request related to a problem? Please describe.

on CI, i always need to have a php composer available in order to create an SBOM of a composer.lock

Describe the solution you'd like

have a bundled .phar added to every release, that includes composer & the CDX composer plugin

Additional context

acc / crit

• phar includes a version of php composer & CDX plugin
• phar bundles pinned versions of all dependencies
  • lock file in the repo
  • add SBOM to PHAR far to know what is in it
• building PHAR is automated part of very release
• CI tests to build PHAR and execute integration/demos on every CT run
• IDEA: https://github.com/humbug/php-scoper is part if build process

benefit: have the config in a file, so no CLI parameters are needed

parameter defaults are read from the config-file, and may override system defaults. parameters can still be overridden via CLI parameters

implementation details: use extra section of the composer file. see https://getcomposer.org/doc/04-schema.md#extra

acc / crit

• [ ] config overrides system defaults (therefore config file settings = presets)
• [ ] CLI params override any defaults/presets
• [ ] parameter type checks are (still) in place
• [ ] parameter plausibility checks are still in place
• [ ] config possibility is documented
  (+ docs have hint, that this config can be used with the gh-action -- see https://github.com/CycloneDX/gh-php-composer-generate-sbom/issues/1)