No, MAIA Software does not require a specific development process, but...
there are activities that are fundamental to implement cross-tool traceability and the necessary “one source of truth” so that everyone has a common view of the development pipeline.
An activity pipeline is a series of activities performed in a predetermined order to deliver a final result.
Create a pipeline by chaining the activities with links between the activities.
Example: to dynamically link a checkout activity to a build activity:
In the MAIA Agent client software :
uuid=$(cat /proc/sys/kernel/random/uuid)
bundle exec maia checkout --component openssl --track main --activity-uuid $uuid
parent_uuid=$uuid; uuid=$(cat /proc/sys/kernel/random/uuid)
bundle exec maia build --component openssl --parent-activity-uuid $parent_uuid --activity-uuid $uuidAn 'external artifact' refers to any software component or module that is not developed in-house but is used in the system. When such an artifact is registered, it is assigned to a component with the same 'name,' which could be a combination of type, vendor, and product name.
Example: the artifact pkg gem/ruby/matrix@0.4.2 gets the component name gem:ruby/matrix. If the component exists, the artifact will be assigned to it. If not, a new component is created.
When opening the component show page, a table presents all artifacts and versions registered by the system.
An SBOM refers to a software library, application, firmware etc. When such an artifact is registered, it is assigned a Product identity, which would be the combination of group (vendor) and name.
Example: An SBOM representing the application com.t2data/epss_cloud@1.3.4 gets the product identity com.t2data/epss_cloud. If the product exists, the artifact will be assigned to it. If not, a new product is created.
When opening the product show page, a table presents all artifacts and versions registered by the system.
For SBOMs, the history is also controlled by the collection of Tags.
To have a reference to a previous version of any software, both identity and tag collection must correspond.
Read here about how Vcs, Homepage and Alt.Link is used
Alt. link is an alternate and manually inserted link address to a component source, superseding Vcs and Homepage. When adding the Alt. link, all versions registered in MAIA/SBOMC, current, previous and future, will have the Alt. link activated.
Pages referenced in this example:
The component is openssl 1.1.1o.
Weblink is set to openssl.org with no usable API for MAIA.
No update information available.
Action 1: open the component index page by clicking the openssl/openssl link in the top the information section.
Read here about how Vcs, Homepage and Alt.Link is used
Alt. link is an alternate and manually inserted link address to a component source, superseding Vcs and Homepage. When adding the Alt. link, all versions registered in MAIA, current, previous and future, will have the Alt. link activated.
Pages referenced in this example:
The component is actioncable 6.1.5.
Weblink is set to rubyonrails.org with no usable API for MAIA/SBOMC.
No update information available.
Action 1: open the component index page by clicking the actioncable link in the top the information section.
MAIA can continuously examine the status of included software artifacts. If a new release is detected, the "Update available" tag will be set.
The information about the release status is provided by the Information Services.
Homepage is a link address to the project that produces the artifact's home page.
Vcs is a link address to the repository containing the artifact.
If one of the link addresses is:
...then MAIA will be able to check the version status of the external artifact.
Homepage and Vcs are automatically set by the system (if possible). The Homepage link may be manually modified, but when upgrading the artifact, the Homepage for that version will be altered, disabling the previous modifications.
Alt. link is an alternate and manually inserted link address to the source, superseding Vcs and Hompage links. When adding the Alt. link, all versions registered in MAIA, current, previous and future, will have the Alt. link activated. A common and helpful situation for the use of Alt. link is when the artifact source links doesn't meet the requirements 1-3 above, but has a code mirroring site that does.
MAIA is prioritizing the links as follows:
A Component is a unit of software identified by its name. An Artifact is a single occurrence of the component i.e. a version of a component.
Currently is the SemVer system the norm, with some extensions. The Semantic Versioning (SemVer) (external link) system is a numbering system with numbers separated by dots, e.g. 1.0.2
The focus is on final releases. Pre-releases, betas, etc. will normally not be considered when examining the version status.
Examples:
Other variants may be applicable.
An artifact refers to physical files that make up a specific version of a software component, application, etc..
An "External artifact" refers to an artifact normally not part of the internal source code development with version control, i.e. an external dependency that is downloaded and included into an application, library, etc.
There are no requirements regarding the origin of an external artifact in MAIA, it's more of a designation.
There could be several reasons why the new release of an external artifact doesn't get an "Update available"-tag.
For example:
There are a number of reasons why the version status cannot resolved for an external artifact, setting it to Unresolved.
First: To be able to be Unresolved, MAIA must be integrated with an external service providing the data, else the status will be No data.
Integration examples:
Then, if:
the verdict will be Unresolved for the version status.
MAIA and SBOMC are integrated with external services to provide users with updates on software security and health information.
The list of integrated services is continuously growing:
An SBOM is a comprehensive inventory of all components and dependencies that make up a version of a software application, library, firmware etc. When such an artifact is registered in MAIA/SBOMC, it is assigned a Product identity, i.e. the combination of group (vendor) and name.
Example: An SBOM representing the application com.t2data/epss_cloud@1.3.4 gets the product identity com.t2data/epss_cloud. If the product exists, the artifact will be assigned to it. If not, a new product is created.
In the CycloneDX standard the application is registered in the sections: metadata :: component :: group where the group often is a shortened, single name of the company or project that produced the component, or the source package or domain name & metadata :: component :: name the name of the component.
When opening the product show page, a table presents all artifacts and versions registered by the system.
For SBOMs, the history is also controlled by the collection of Tags.
To have a reference to a previous version of any software, both identity and tag collection must correspond.
Currently CycloneDX 1.3-1.6 (json) is supported.
Are detected vulnerabilities continuously monitored regarding status changes?
The answer is yes!
Example: The notification page shows both added and removed vulnerabilities .
MAIA assigns an internal Priority parameter to all vulnerabilities. The table that contains vulnerabilities for the Built artifact is sorting them by Priority, starting with Critical at the top, and within each group, the vulnerabilities are sorted by identity.
By default, the Priority is set to Priority=CVSS, i.e., Low, Medium, High, or Critical. The priority may automatically be set to None by an external information service collecting Patch data.
The Priority may in a later stage be changed in the Analysis process.
The CVSS (Common Vulnerability Scoring System) sets a score to a vulnerability, rating the severity (0-10). The overall CVSS score is composed of three sub groups of metrics (Base, Temporal, Environmental), of which each group has several subcomponents.
The value of the overall CVSS Score may depends on the context, i.e. if the score is of general type or if it is related to a specific software.
Summary: A vulnerability may have multiple CVSS scores depending on current context. One value may be valid for a set of software, and another value for another set, depending on separate analyses.
The Priority:
An Active user is a user that is member of at least one Team.
A user must be Active to be able to log in and interact with SBOM Central.
As soon as an Active user is removed from all Teams the user will be deactivated, but not removed from the system. The user may later on be re-activated when added to a Team.
The licensing model sets a limit to the number of Active users.
TODO...
IMPORTED THROUGH THE VERSION CONTROL
Old users, currently not part of the daily MAIA workflow, are probably still an important part of the history.
An old user, when deactivated, does not affect any licensing costs but is still an important placeholder for historic activities in MAIA.