Software Evidence Archive (SEvA)


john
 

Hi All:
I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 
thanks, js

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >
www.selectpress.net


Alan Tse
 

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@...
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >


john
 

SPDX seemed to only contain data around licensing and bills of materials (for dependencies) but didn’t include data around what tests were run, virus scanning, etc. results for a particular build of software or source  code. 

the main part for non-commercial was to limit license forking 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >
www.selectpress.net

On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...) wrote:

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@...
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >


Kate Stewart
 

Hi John,
    Thanks for sharing the information on SEvA.   

    In scanning through the repository,  its not clear to me that when you're using <licenses>3DFX</licenses>, are you expecting them to licenses 
off the SPDX license list?   are SPDX license expressions ok?

Also,   for the fields that are in common with SPDX (Software Package Data eXchange),  
to promote interoperability,  are you using the same data formatting/parsing constraints?
I can't quite tell from the descriptions I'm finding, but feel free to point me to details. :-)
The package level fields that are likely to overlap with SPDX are described in

Also, If you want to propose the format for some of the fields that the SPDX
specification doesn't have,  we're working on the 2.2 version of the specification
at the moment, and submitting issues to the github repository, gets the proposal
on the discussion list. 

Kate


On Thu, Feb 22, 2018 at 6:09 PM, John Scott <john@...> wrote:
SPDX seemed to only contain data around licensing and bills of materials (for dependencies) but didn’t include data around what tests were run, virus scanning, etc. results for a particular build of software or source  code. 

the main part for non-commercial was to limit license forking 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >

On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...) wrote:

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@lists.linuxfoundation.org
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >


_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain



Camille Moulin
 

Hi Scott,

Thanks for sharing, tt seems very interesting.

One question about the licence, though: why the NC clause in your CC-BY-NC-SA-3.0 licence ?

Best,

Camille


Le 22/02/2018 à 23:54, John Scott a écrit :

Hi All:
I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 
thanks, js

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >


_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Steve Cropper
 

Hi John:

Some good work here.

SPDX version 2.0... was created with a software supply chain in mind. 

It seems to me that SPDX would be a subset of the data you want to track but should form a basis for what you want to do. There is flexibility in the spec to allow additional information, similar to that you have indicated, using the File or Annotation properties. 

Using the “File Information” you could supplement the SPDX content with an xml/rdf or other file with your specific meta data additions and use the file meta data to describe the file it’s usage and licensing.

Using the “Annotations” property you can provide package “review” type information or “other” information that can contain the information you intend to capture. Since the “Annotation Comment” is free form text you can insert formatted meta data if you wish.

As Kate and others have said, if you think the meta data you are capturing has a wider application then I would encourage participation in the SPDX working group to propose spec enhancements.

Best Regards
Steve

Steve Cropper
+44 7982 525 965


On Feb 23, 2018, at 00:09, John Scott <john@...> wrote:

SPDX seemed to only contain data around licensing and bills of materials (for dependencies) but didn’t include data around what tests were run, virus scanning, etc. results for a particular build of software or source  code. 

the main part for non-commercial was to limit license forking 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >

On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...) wrote:

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@...
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


JC Herz <jc.herz@...>
 

Hi -

The intent is to prevent an entity from assembling, packaging and charging for SEVAs as a free rider. So for instance: load a bunch of projects into Ion Channel via API, extract the result and resell as a commercial product. 

Any commercial entity would be able to use SEVAs for their own internal security purposes, but not as third-party certification or attestation to sell their product. If they want that (i.e. it has business value) it makes sense for them to sign up for a subscription that confers that right.

If there’s a narrower non-resale license that serves that purpose, would be grateful for a link or reference to it.



JC



On Feb 22, 2018, at 7:09 PM, John Scott <john@...> wrote:

SPDX seemed to only contain data around licensing and bills of materials (for dependencies) but didn’t include data around what tests were run, virus scanning, etc. results for a particular build of software or source  code. 

the main part for non-commercial was to limit license forking 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >

On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...) wrote:

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@...
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >



Paul Sherwood
 

Hi JC,
On 2018-02-23 06:12, JC Herz wrote:
The intent is to prevent an entity from assembling, packaging and
charging for SEVAs as a free rider. So for instance: load a bunch of
projects into Ion Channel via API, extract the result and resell as a
commercial product.
For that use case, wouldn't it make more sense to inform API users directly when they sign up? This seems to be a separate concern from the license on the format/standard and the code in that repository.

Any commercial entity would be able to use SEVAs for their own
internal security purposes, but not as third-party certification or
attestation to sell their product.
I don't think the chosen license makes that clear.

If they want that (i.e. it has
business value) it makes sense for them to sign up for a subscription
that confers that right.
This seems to agree with my first comment above.

If there’s a narrower non-resale license that serves that purpose,
would be grateful for a link or reference to it.
Depends on your views of the above, I think.

<snip>
On Feb 22, 2018, at 7:09 PM, John Scott <john@...>
wrote:
the main part for non-commercial was to limit license forking
Not sure what John meant by this.

To echo what Alan said, the NC license is bound to discourage some potential adopters. I considered looking into SEVA as a potential format/approach for a customer project, but I charge for my time and they charge for what I help them create. The current license makes me think I shouldn't even download the repo.

Incidentally a quick browse on GitHub suggests that some of the SEVA content may be copied or derived from elsewhere (e.g. https://github.com/NIEM/NIEM-NDR), which is not licensed NC as far as I know.

br
Paul

-------------------------------------------
John Scott, President
Selection Pressure LLC
240.401.6574 @johnmscott
< john@... >
www.selectpress.net [3]
On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...)
wrote:

Thanks for sharing. Some questions:
1. Is your intent with the non-commercial use provision to
mean no commercial entities can use the format? Or was it to
prohibit people from charging? If it’s the latter, the license
choice may be too broad. An issue I see with a NC license is that
this may limit any potential adoption because commercial entities
are primarily the entities that would use this type of data.
2. Have you taken a look at SPDX [1] for the license
meta-data? While SEvA is a broader solution, there may be some
duplication in efforts on the license side that can be avoided.
ALAN D. TSE
FROM: openchain-bounces@...
[mailto:openchain-bounces@...] ON BEHALF OF
John Scott
SENT: Thursday, February 22, 2018 2:55 PM
TO: openchain@...
SUBJECT: [OpenChain] Software Evidence Archive (SEvA)
Hi All:
I’ve been on the list for a while and wanted to share some work
we’re been doing. The issues we’ve been trying to solve is the
portability and sharing of meta-data around a piece of software.
For instance analysis that is completed in one place and needs to
move with the software.
To solve that we’ve come up a with a XML/JSON format to ship
results around, GitHub repo here:
https://github.com/ion-channel/SEVA
thanks, js
SOFTWARE EVIDENCE ARCHIVE (SEVA)
SEvA is specification for encapsulating software supply chain
metadata and delivering with a clear and concise schema for
parsing using automation. The SEvA definition is divided into
several sections. There is a brief description of each section
listed below.
LICENSE
[2]
This work is licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 3.0 United States License
[2].
PRODUCT AND VERSION INFORMATION
Contains any product naming or version related information.
FILE AND MIME TYPE INFORMATION
Contains any file types detected within the source artifact or
source repository. It also contains the related mime types for
each file detected.
AUTHORITATIVE SOURCE INFORMATION
Contains any information about what is to be considered the
authoritative source for ad given artifact or source repository.
This includes a URL, hash of the source and whether or not the
source has been signed.
ECOSYSTEM AND COMMUNITY INFORMATION
Contains information pertaining to a software projects ecosystem
(programming languages, urls, etc.) and community information
(number of committers, mailing list activity, overall sentiment,
etc).
DEPENDENCY INFORMATION
Contains a list of dependencies (naming, versions,
vulnerabilities) for a given software project derived directly
from the artifact or source dependency definition file.
LICENSE INFORMATION
Contains any license information detected from a given artifact or
source.
VULNERABILITY AND VIRUS INFORMATION
Contains any vulnerability or virus definitions detected from the
artifact or source repository.
RESULT OF GRC INFORMATION
Contains the calculated risk and compliance to governance from the
analysis of the software artifact or source repository.
DELIVERY INFORMATION
Contains any delivery information including the target url and
last delivered date and time. This will not include any
information for the current delivery as the seva is signed prior
to delivery.
-------------------------------------------
John Scott, President
Selection Pressure LLC
240.401.6574 @johnmscott
< john@... >
www.selectpress.net [3]
Links:
------
[1] https://spdx.org/
[2] http://creativecommons.org/licenses/by-nc-sa/3.0/us/
[3] http://www.selectpress.net/
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain