Overview

Description Here
Refactor Merger to completely accommodate for new internal SBOM changes.

Acceptance Criteria

• Merger completely accommodates new SBOM Object.
• Two CycloneDX SBOMs can be merged into a single CycloneDX SBOM.
• Two SPDX SBOMs can be merged into a single SPDX SBOM.
• An SPDX and a CycloneDX SBOM are merged into a single SVIPSBOM.
• ~90% Code Coverage

Overview

The current Quality Report generates a massive JSON file of information. To reduce information overload, we can truncate the data that is returned based on parameters for the /qa endpoint.

Acceptance Criteria

• getAllTests - Get the Entire Report
• getFailingTests - Get only failing tests
• getPassingTests - Get only passing tests

Overview

Description Here
Refactor Generators to match new internal SBOM changes.

Acceptance Criteria

• Completely supports new SBOM object.
• ~90% Code Coverage

Overview

Create the VEX factory.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

• Restructure the VEX UML to fit the Builder Pattern.
• Receive data from the Frontend API request (1)

• SBOM ID
• API Key

• Gather requirements for making an OSV and NVD API request (1)

• OSV
• NVD

• Extract required data from the target SBOM (1)
• Abstract HTTP Client (2)

• OSV HTTP Client and API call (1)
• NVD HTTP Client and API call (1)

• Parse OSV response for VEX Object data (2)
• Parse NVD response for VEX Object data (2)
• Compile and return VEX Object tor Frontend (1)

Misc.

• ~80% Code Coverage

Description:

if applicable
Expected Output:
Actual Output:
Link to Source Material (e.x. project github):
Relevant Screenshot(s):

Overview

The goal of this issue is to get the backend/API running on its own in a Docker container.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

• Setup Dockerfile to build core & api packages and serve the API on port 8080.
• Document how to build & run the image.
• Test API endpoints using Postman to make sure they work

Overview

Use the respective component builder interfaces to create component builders.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

Builders

• SPDX 2.3 File Builder
• SPDX 2.3 Package Builder
• CDX 1.4 Package Builder
• SVIP Component Builder

Misc.

• ~80% Code Coverage

The current SPDX Metrics Processor in SoftwareDesignLab/SBOM-Plugfest#171 is partially complete, but is missing a few fields that need a more robust SBOM object before implementation.

• hasDocumentName
  • A field in the SBOM metadata that is required
• hasVerificationCode
  • Check if a package has a unique identifier based on the files inside it (one if FilesAnalyzed is true or omitted, zero (must be omitted) if FilesAnalyzed is false)
• hasExtractedLicenses
  • Check if there are any licenses in the project that are not on the SPDX license list, and if so, list them
• hasExtractedLicensesDescriptions
  • If there are extracted licenses, check to see if they have descriptions attached.
• hasExtractedLicensesRef
  • If there are extracted licenses, check to see if they have a valid listed reference link.

See above screenshot for example. To replicate this, simply run all tests in GradleParserTest. Some dependencies just do not exist on Sonatype. For example, the org.springframework.spring-oop package has no results when searching Sonatype.

Two possible solutions - either avoid logging and just print a debug line saying no package found on Sonatype, or use a different repo??

Resources

• CLI Tool
• CLI Docs

Acceptance Criteria

• Investigate using Sonatype as a repository source
• Use alternate source if needed

Overview

Currently CDX translators extract metadata and application tools from SBOM. TranslatorSDPX.java should have the same functionality

Acceptance Criteria

• TranslatorSPDX extracts all metadata and tools and populates the SBOM metadata object.
• Add unit tests to test correct metadata functioning

Overview

Create CDX1.4 JSON and SPDX2.3 JSON / Tag-Value serializers based on the UML specs.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

• Update UML architecture

• SerializerFactory Class

  • Utilizes InvalidFormatException

• Serializer Abstract Class

  • CDX14JSONSerializer Class
  • SPDX23JSONSerializer Class
  • SPDX23TagValueSerializer Class
  • SVIPSBOMJSONSerializer Class

• ~90% Code Coverage

Overview

Using the CDX1.4SBOMBUilder interface, create an object for the builder.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

Class Features

• format
• name
• uid
• version
• specVersion
• licenses
• creationData
• documentComment
• rootComponent
• components
• relationships
• externalReferences
• vulnerabilities
• services
• compositions
• signiture
• CDX1.4Builder()

Misc.

• ~80% Code Coverage

The BenchmarkParser currently performs an individual isInternalComponent() by walking the filetree each time. Instead, we should build a live representation of the file-tree at program start once and query that instead of re-walking the tree over and over again

Overview

The backend will be replacing the current metrics endpoint to return a SBOM object instead with metrics integrated within it to account for both metadata and component testing.

Acceptance Criteria

• Format SBOM object with backend team
• Approval from Derek
• Check with R.E.S.E.A.R.C.H group for approval of new format
• Test with Quality Report
• Implement Quality Report format into Plugfest

Overview

SBOM currently stores Hash object and should be storing strings instead. See SoftwareDesignLab/SBOM-Plugfest#139 for CPE implementation and SoftwareDesignLab/SBOM-Plugfest#134 for PURL implementation.

Acceptance Criteria

• SBOM Object stores only hash strings, not Hash objects
• Hash Object is refactored to function similar to PURL and CPE Objects
  • Hash throws error if attempt to make an invalid Hash object

Overview

Create the SBOM Builder Factory interface and the respective SBOM Builder Factories.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

• SBOM Builder Factory Interface
• CDX 1.4 SBOM Builder Factory
• SPDX 2.3 SBOM Builder Factory
• SCIP SBOM Builder Factory

Misc.

• ~80% Code Coverage

The LicenseManager.parseLicense() method incorrectly assumes certain licenses based on the way it tokenizes. This is independent of the SBOM schema being generated.

Overview

Create the initial interfaces for the Component Builders.

Related SVIP System Requirement IDs

2.2: The system shall allow users to upload any SBOM, regardless of origin format

Acceptance Criteria

• CDX14PackageBuilder_I
• ComponentBuilder
• SBOMComponentBuilder
• SPDX23ComponentBuilder
• SPDX23FileBuilder_I
• SPDX23PackageBuilder_I

Overview

Instead of storing uploaded files in a HashMap, we need to store them in a database server. This can be achieved by running a MySQL server in a separate Docker container and using the JPA library to connect and execute transactions.

Related SVIP System Requirement IDs

• 7.4: The system shall store SBOM files in a database

Acceptance Criteria

• Create docker-compose file to generate multiple containers (our backend and a MySQL server instance) on startup.
• Integrate MySQL server with backend.
  • Create models
  • Add a service/controller class to interact with the MySQL server
  • Add CRUD operations to the upload, view, & viewFiles endpoints in #62.
• Fix SQL strings auto-truncating/throwing errors.
• Fix unit tests to use a mock DB instance for testing.

Stretch Goals

• Create a script to ONLY run the MySQL database in Docker to make it easier to develop and test the API
• Use Hibernate to store translated SBOMs in a separate table

The current CDX Metrics Processor in SoftwareDesignLab/SBOM-Plugfest#170 is partially complete, but is missing a few fields that need a more robust SBOM object before implementation. See related #52

• HasCompositionAggregate
  • Given that compositions are present in the SBOM, check that each composition contains an aggregrate (must be: "complete", "incomplete", "incomplete_first_party_only", "incomplete_third_party_only", "unknown", "not_specified")
• HasExternalRefSpecs
  • Given that external references are present, check if each one at least contains a url and type (type must be: "vcs", "issue-tracker", "website", "advisories", "bom", "mailing-list", "social", "chat", "documentation", "support", "distribution", "license", "build-meta", "build-system", "release-notes", "other")
• HasServicesName
  • Given that services are present, check that each service has a name
• HasDependenciesRef
  • Given that dependencies are present, check that each dependency contains a ref to a component's bom-ref

Overview

The current Uniqueness Processor in SoftwareDesignLab/SBOM-Plugfest#134 is almost complete, but is missing a few fields that need a more robust SBOM object before implementation. See related #45

Acceptance Criteria

• ValidSWIDTest
  • Similar to CPE/PURL, use Object for testing
• AccuratePURLTest
  • Need to find a way to check namespaces in a purl. Different package managers use the PURL namespace for different information (vendor, group, organization/user, etc)

The CDX Metric Processor contains a test, hasBomRef, that checks that components have some form of identifier. TranslatorCDXJSON does have this in place (typically is the purl as the bom-ref), but TranslatorCDXXML does not.

While most bom-refs are just the component's purl, if it is a different value, our check would produce false results.

• implement bom-ref checks in TranslatorCDXXML.java

There are numerous fields required in a CycloneDX document that go beyond the minimum SBOM requirements. Having information from these fields and their required elements (listed below) would help create a more extensive and rigorous CDX Metrics Processor if a given SBOM includes these elements.

compositions:

• Aggregate

externalReferences:

• url
• type

services:

• name

dependencies:

• ref

Overview

The current Completeness Processor in SoftwareDesignLab/SBOM-Plugfest#139 is almost complete, but is missing a few fields that need a more robust SBOM object before implementation

Acceptance Criteria

• ValidSWIDTest
• We don't test for SWIDs. More research needs to go into understanding how they work and how to best represent them.
  • Research SWID Representation
  • Create SWID Object to use for testing
• HasRelationshipTest
• This can be folded into MinElementsTest.

Overview

Create an interface for the Component Builder Factory, then create the respective Component Builder Factory classes.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

• Component Builder Factory Interface
• CDX 1.4 Package Builder Factory
• SPDX 2.3 Package Builder Factory
• SPDX 2.3 File Builder Factory
• SVIP SBOM Component Factory

Misc.

• ~80% Code Coverage

CDX (Done)

• CycloneDX v1.4 XML Reference
• Official XML examples

SPDX (Done)

• Official RDF XML example

Overview

Clean up and revise the current Metrics system, as well as refactor it to work with the new SBOM objects.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

• API Documentation (1)
• QA Pipeline (1)
• Metric Tests (2)
• Result Factory (1)

Unit Tests (~80 Coverage)

• QA Pipeline
• New Metric Tests
• Result Factory

If you close the Electron instance too quickly on Mac, the backend will still build and remain running after close.

Overview

Add all relevant api/core constants (i.e. version numbers, etc.) to the .env file instead of having them hardcoded. Also, find the best way to establish an "example" config so we don't have .env files in the root of the repository.

Related SVIP System Requirement IDs

• N/A

Acceptance Criteria

• Add all relevant api constants to the .env file.
  • Use spring annotations to reference these at compile time.
• Add all relevant core constants to the .env file.
  • Use annotations (is this possible in the core package?) to reference these at compile time.
• Create "template" .env.example file and add .env to the gitignore.

This occurs in both JSON and XML. The import * should be fixed in #7 eventually, but the import statements and carriage returns still occur in the name. This should not be the case.

https://github.com/SoftwareDesignLab/SVIP/blob/639ac98c249de35bccc121d41c8b9b399358b255/doc/README.md?plain=1#L1

Outdated references to building old SVIP that will need to be updated

Overview

Get upload, view, & viewFiles endpoints implemented on the SVIP backend for front-end.

Related SVIP System Requirement IDs

• 2.2: The system shall allow users to upload any SBOM, regardless of origin format

Acceptance Criteria

• upload
  • Takes in an SBOMFile in the request body - fileName & contents value.
  • Caches the raw file on the backend.
  • Returns the unique ID of the uploaded file.
  • Unit Tests
• view
  • Takes in an ID in the request parameters and returns the contents of that file.
  • Unit Tests
• viewFiles
  • Returns all IDs of files stored on the backend.
  • Unit Tests
• delete
  • Takes in an ID in the request parameters and deletes the file.
  • Unit Tests
• Update API documentation

Overview

Create an SVIP SBOM builder using the CDX 1.4 and SPDX 2.3 SBOM Builder interfaces.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

Class Features

• - format: String
• - name: String
• - uid: String
• - version: String
• - specVersion: String
• - licenses: Set
• - creationData: CreationData
• - documentComment:String
• - rootComponent: Component
• - components: Set
• - relationships: HashMap<String, Set>
• - externalReferences: Set
• - vulnerabilities: Set
• - services: Set
• - compositions: Set
• - signature: Signature
• - snippets: Set
• - additionalLicenseInformation: Set
• - annotaionInformation: Set
• - SPDXLicenseListVersion: String
• + SVIPSBOMBuilder():SVIPSBOMBuilder

Misc.

• ~80% Code Coverage

https://github.com/SoftwareDesignLab/SBOM_WorkingGroup/blob/92f4f38f5d10d69d34e6fb3b95ecdd793e0c378c/SVIP/src/main/java/com/svip/osi/VEXFactory.java#L68

We shouldn't be storing user data in the VEXFactory. We should just use it to try can login to NVIP to get a new connection instance

Overview

Create the initial interfaces for the SBOM Builders.

Related SVIP System Requirement IDs

2.2: The system shall allow users to upload any SBOM, regardless of origin format

Acceptance Criteria

Interfaces

• SBOMBuilder
• CDX1.4SBOMBuilder
• SPDX2.3SBOMBuilder

Overview

Create an SPDX 2.3 SBOM builder using the SPDX 2.3 interface.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

Class Features

• - format: String
• - name: String
• - uid: String
• - version: String
• - specVersion: String
• - licenses: Set
• - creationData: CreationData
• - documentComment:String
• - rootComponent: Component
• - components: Set
• - relationships: HashMap<String, Set>
• - externalReferences: Set
• - vulnerabilities: Set
• - snippets: Set
• - additionalLicenseInformation: Set
• - annotaionInformation: Set
• - SPDXLicenseListVersion: String

Misc.

• ~80% Code Coverage

There is an edge case where nuget project configurations are formatted like this. I don't see a single instance apart from the Microsoft docs: https://learn.microsoft.com/en-us/nuget/reference/nuspec

At the moment NugetParser is unable to parse this format

When comparing two DependencyTrees using their equals() methods, only the component names are compared. This is because the current quick-and-dirty fix for comparing two DependencyTrees uses simple string comparison to remove the need for UUIDs.

• The toString() method in equals() is mainly generated from the following method:
  
• This essentially replaces the internal dependencyMap with an indented list of values. Currently, only the component names are compared and generated in the string
  • This is due to the fact that the SBOM objects used for testing currently only provide a component name. See #30 for details on this.

2023-05-10 14:32:13.251 | EXCPT | NullPointerException | Cannot invoke "java.util.List.add(Object)" because "this.files" is null | org.svip.sbomfactory.generators.utils.ParserComponent.addFile(ParserComponent.java:107)

How to recreate:

Snippets from CycloneDX JSON generator output from the Java test project:

Not sure why the first component doesn't have a filepath, this may be insightful as to why there are duplicates. As far as I know, no duplicate checker exists in either the generators or parsers. This should be added in ParserController.

Overview

Create CDX1.4 JSON and SPDX2.3 JSON / Tag-Value DEserializers based on the UML specs.

Related SVIP System Requirement IDs

• SVIP System Requirement IDs Here

Acceptance Criteria

• Update UML architecture

• SerializerFactory Class

• Deserializer Abstract Class

  • CDX14JSONDeserializer Class
  • SPDX23JSONDeserializer Class
  • SPDX23TagValueDeserializer Class

• ~90% Code Coverage

This occurs in both JSON and XML.

Overview

Add the endpoint for report downloads.

Related issue: https://github.com/orgs/SoftwareDesignLab/projects/6/views/5?pane=issue&itemId=32511692

Related SVIP System Requirement IDs

• 1.3.1 | The system shall support CycloneDX 1.4 SBOM output
• 1.3.2 | The system shall support SPDX 2.3 SBOM output
• 3.6 | The system shall allow the used to download JSON VEX reports
• 4.4 | The system shall allow users to download raw JSON reports of Metric findings
• 5.3 | The system shall allow users to download raw JSON reports of Comparison findings

Acceptance Criteria

• Develop an agreed upon download API endpoint with Frontend
  • Update API documentation
• Implement the endpoint to access the SQL database
• Return the SBOM file requested
• Endpoint must be expandable to access future DB entries
• ~90% Code Coverage

Currently, our translators only collect information on top-level components and no children. If we want to have more flexibility with our SBOMs and sub-dependencies in the future, we will need to collect this.

• If a child component is added to a component already in the SBOM, the generator tests will fail:

Test SBOM initialization methods

These are arbitrary, the only difference between these and the current tests in CycloneDXSerializerTest are the amount of children.

Test Output

The output after generating CDX JSON files from the SBOMs, translating them back in, and then comparing them:

• Note the missing child components
• This also occurs in all other translators as well
  

Currently, the tests for generator serialization use multiple different instances of SBOMs, most with one or two simple ParserComponents that only have a name attribute.

Create a static method somewhere that returns an SBOM that has everything we want to test (licenses, file references, version, publisher, children of children, etc.) and use that to replace all test SBOM instances in the generator tests.

• It is likely that #28 will need to be resolved beforehand.

At the moment, neither scrape publisher/contributor info. This can be done in PackageManagerParser.buildURLs

Example 1:

Example 2:

• Comments and multi-line comments are included as components when being parsed
• These also contain non-SBOM friendly characters, such as carriage returns and unnecessary whitespace before and after

.dep files include both import library and import library.* statements.

Currently, we only have a translator for SPDX tag-value format (.spdx). Our generator supports JSON, XML, & YAML as well, so these will need to be implemented at some point.

• After implementation, there will also be test cases to create for SPDX JSON, XML, & YAML serialization.
• See CycloneDXSerializerTest for an example of how a file is generated and then translated back to test expected output.