cjson esp-idf-sbom seems does not recognize sbom_cJSON.yml (IEC-560)

[AxelLin]

Answers checklist.

• I have read the component documentation ESP-IDF Components and the issue is not addressed there.
• I am using target and esp-idf version as defined in component's idf_component.yml
• I have searched the issue tracker for a similar issue and not found any related issue.

Which component are you using? If you choose Other, provide details in More Information.

cjson

ESP-IDF version.

v5.5.4-1242-g10ca0dff2f4

Development Kit.

ESP32-WROOM

Used Component version.

1.7.19~2

More Information.

I have added "espressif/cjson: ^1.7.19~2" to idf_component.yml in my application and use the cjson component.

When I do "esp-idf-sbom create" and "esp-idf-sbom check",
I found
│ component-espressif__cjson │ 1.7.19~2 │
in "Packages without CPE and Keyword Information".
This seems worng.

If I manually rename components/espressif__cjson/sbom_cJSON.yml to components/espressif__cjson/sbom.yml,
I got: (The expected output)
Packages with No Identified Vulnerabilities
│ cJSON │ 1.7.19 │ cpe:2.3:a:cjson_project:cjson:1.7.19:::::::, cpe:2.3:a:davegamble:cjson:1.7.19::::::: │

So it looks like the tool does not find sbom_cJSON.yml.

esp-idf-sbom seems does not recognize sbom_cJSON.yml in cjson componenet.

$ esp-idf-sbom --version
esp-idf-sbom 1.3.0

[fhrbata]

Hi @AxelLin, thanks for the detailed report. This is a known issue and
we already have a fix in progress. You also diagnosed it correctly: the
problem is not in esp-idf-sbom itself, but in how the component is
packed and served by the component registry.

Root cause

cjson ships its SBOM data in sbom_cJSON.yml and points at it from
idf_component.yml:

sbom:
  manifests:
    - path: sbom_cJSON.yml
      dest: cJSON

When the component is uploaded to the registry, idf_component.yml is
regenerated from the component manager's manifest model, and that model
does not currently declare an sbom field. As a result, the sbom: key
is silently dropped from the served idf_component.yml.

You can confirm this in the downloaded component: sbom_cJSON.yml is
present and intact under managed_components/espressif__cjson/, but the
sbom: block that referenced it is gone from the served
idf_component.yml.

esp-idf-sbom reaches a component's referenced manifest
(sbom_cJSON.yml) only by following that sbom: pointer. With the
pointer removed, the file is orphaned and never read, so cJSON ends up
in "Packages without CPE and Keyword Information".

Why your rename works: esp-idf-sbom also auto-discovers any file named
exactly sbom.yml by scanning the component directory, no pointer
needed. So renaming sbom_cJSON.yml to sbom.yml makes it visible
again, and the CPEs reappear.

Fix

We already have a fix in progress in the component manager: it declares
sbom as a manifest field so the key survives the upload/fetch round
trip. Once it is released and cjson is re-published with the fixed
manager, the served archive will carry the sbom: pointer again and no
workaround will be needed.

Note that re-publishing is required: the fix in the manager only affects
new uploads, so the already-published 1.7.19~2 will keep this behavior
until the component is re-published.

Meanwhile

Your workaround (renaming sbom_cJSON.yml to sbom.yml in the
downloaded component) is valid as a stopgap. Keep in mind it lives under
managed_components/, so it is overwritten if you clean or re-fetch the
component and would need to be reapplied.

cc @kumekay (component manager)

[kumekay]

@AxelLin We are planning to push the fix at the begging of the next week. I'll update this issue once it will be published.

[AxelLin]

Fix

We already have a fix in progress in the component manager: it declares sbom as a manifest field so the key survives the upload/fetch round trip. Once it is released and cjson is re-published with the fixed manager, the served archive will carry the sbom: pointer again and no workaround will be needed.

Note that re-publishing is required: the fix in the manager only affects new uploads, so the already-published 1.7.19~2 will keep this behavior until the component is re-published.

@fhrbata

This means you are not sure when the impacted component will re-publish.
For example, cjson is not a frequently update component, it may take quite long time to get update.
Adn there are other components with this issue.

[fhrbata]

@AxelLin ,

looking at this a little bit more, this seems like a generic problem with most of the components in the idf-extra-component repository. I will try to work around this problem on the esp-idf-sbom side, so the generated sbom contains proper information even before this is fixed on the component manager side and new component versions are released.

Thank you!

[fhrbata]

Hi @AxelLin,

Some background on why this happens, since it may be reassuring: this setup used to work. The sbom: pointer in idf_component.yml was carried into the published archive until the component manager rewrote its manifest handling with pydantic in 54ff963 (March 2024, released in the v2.0 line). Before that change, extra manifest keys were preserved as-is. After it, idf_component.yml is regenerated from a model that does not declare an sbom field, so Manifest.model_dump() silently drops the key on upload.

You can still see the earlier behavior in fmt: it was last published in July 2024 with a v1.x manager, and its served idf_component.yml still contains the sbom: block, while components published afterwards lost it.

The component manager fix (4bfcf84) re-declares the field so it round-trips again. In the meantime I will try to work around it on the esp-idf-sbom side, as noted above, so that already-published components can still produce correct SBOM output without waiting for each one to be re-published.

Thank you!

[kumekay]

@AxelLin The fix on the Component Registry side was deployed, so field won't be dropped for new uploads, but we cannot re-process existing versions, because it would change hash-sum and this is against registry guaranties.