Skip to content

Add advisory-based VCIO API support with backward-compatible normalization layer#2067

Closed
dikshaa2909 wants to merge 1 commit intoaboutcode-org:mainfrom
dikshaa2909:migrate-vcio-advisory-api
Closed

Add advisory-based VCIO API support with backward-compatible normalization layer#2067
dikshaa2909 wants to merge 1 commit intoaboutcode-org:mainfrom
dikshaa2909:migrate-vcio-advisory-api

Conversation

@dikshaa2909
Copy link

Summary

Addresses #2002

Add support for advisory-based VCIO API responses while preserving compatibility with the existing vulnerability-based model.

Changes

  • Introduced extract_security_entries() to centralize security entry handling.
  • Added normalize_advisories() to map affected_by_advisories into the existing vulnerability-compatible structure.
  • Preserved current affected_by_vulnerabilities behavior (no schema changes).
  • Added tests covering:
    • Advisory-based responses
    • Backward compatibility
    • Unexpected/empty API responses

Migration Strategy

The VCIO API is migrating from vulnerabilities to advisories.
This PR adds a minimal normalization layer to support both formats without requiring model, template, or database changes.

This enables phased migration while keeping the integration stable and backward compatible.

…rmalization

Signed-off-by: dikshaa2909 <dikshadeware@gmail.com>
@dikshaa2909
Copy link
Author

Hi @TG1999 could you please review this PR when you get a chance? Thank you!

@dikshaa2909
Copy link
Author

Hi @tdruez @pombredanne @TG1999 can u pls review it when u have time ! Thanks !

@AyanSinhaMahapatra
Copy link
Member

AyanSinhaMahapatra commented Mar 10, 2026

This PR doesn't change the majority of the code in https://github.com/aboutcode-org/scancode.io/blob/main/scanpipe/pipes/vulnerablecode.py which uses the old API to get vulnerabilities data, but just performs a very basic data normalization, instead of using the new API/data and refactoring all the changes required.

This is a large, complex task and @dikshaa2909 please do not submit PRs which are spam/low effort/vibe coded, without even running/passing the tests locally, as this wastes the maintainers time. This also negatively affects getting selected into GSoC.

Closing!

@dikshaa2909
Copy link
Author

@AyanSinhaMahapatra
Thanks for the feedback and for reviewing the PR. Apologies for the noise caused. I understand the concern and will take more time to review the existing implementation and ensure tests pass locally before submitting future PRs. Appreciate the guidance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants