Trustify Readme feedback

[ptomanRH]

// I would like to have a better more accessible description of the project for the community. Please provide a feedback, bring sugegstions what to include/exclude.
//

Trustify

Welcome to Trustify, an open-source platform bringing together Software Bills of Materials (SBOMs) and security advisories to ensure security threats and vulnerabilities are minimized and caught promptly.

How Trustify Helps

Trustify tackles some of the problems developers and companies face when keeping software safe and organized. Here’s how it helps:

• Meet compliance regulations for SBOM management and archiving
• Deploy applications with fewer vulnerabilities
• Know that trusted components are in use as early as possible
• Reduce alert fatigue with fewer false positive by getting vendor vulnerability information from the actual vendor (VEX)
• Analyze applications without downloading and installing

Architecture

Trustify is the next evolution of the Trustification project.
We changed the architecture to modulith approach, to build a simpler-to-deploy more responsive system that can flexibly meet the needs of the company and our customers going forward.

The general architecture is as follows:

The System

• REST APIs to support operations for ingesting and retrieving supply-chain data.
• Actively loads vulnerability/advisory information from a variety of sources as it becomes available, regardless of components currently-known.

A single SQL database

• PostgreSQL.
• Expandable data-model to support all aspects of supply-chain data.
• OIDC provider

[Charlesnorris509]

@ptomanRH Well looking at your design architecture, I think that overall your system seem more or less correct since I dont have the specific functional requirements you are given, however because I am assuming that you want to create some form of microservice based architecture, you should take non functional requirements like fault tolerance, perfomance and scalability into consideration. For example I would insert some message queue in front of the database to manage concurrant request, and have an API gateway between the client and the server to manage things like authentication, routing and rate limiting. I would also have some form of cache memory to fasten read requests. And since you are managing security events have some form of notification system like AWS SNS to give update on the platforms activities

[dejanb]

@ptomanRH this looks good to me. Can you raise PR with these changes to the README?

@Charlesnorris509 The architecture is like this by intention. The system can be run as a single binary, or as set of services (as you implied), but only if the load requires it. As this is a data-intensive application, properly scaling the database is bigger priority.