Re: Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)
It is interesting to see Software Asset Management being referenced. I have been involved in SAM since the late 90's. I was part of a non-profit call Investors in Software that formed to drive standards in managing software (at the time proprietary) which led to the publication of ISO/IEC 19770-1 Standard for Software Asset Management which is a process standard
There is also ISO/IEC 19770-2 Software ID Tagging Standard which is an XML Tag definition to tag software that needs to be licensed. https://www.iso.org/standard/53670.html which in a way is similar to SPDX
When I worked at Microsoft we created a maturity Assessment (see attached) which rated different processes with a maturity rating rather than a binary yes/no.
I still have a connection with the working group for ISO SAM/ITAM standards (WG 21) and have tried to get open source software on their radar.
In UK and Europe SAM is broadly adopted. There are full time employees and in some cases teams solely dedicated to SAM/ITAM. The principles as regards processes for SAM are similar to what is required to managed SAM.
If you think there is mileage in a liaison with WG21 I could pursue it.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Foster, Jeremiah
Sent: 09 August 2017 16:28
To: email@example.com; firstname.lastname@example.org; email@example.com
Subject: Re: [OpenChain] Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)
On Wed, 2017-08-09 at 08:33 -0400, John Scott wrote:
There are a number of projects the US government is working on. Essentially these projects are about creating artifacts to approve system to operate (Authority to Operate) - ATO). I’m involved in most of these
themes useful one right now is Project Boise aims to update the federal government’s software security compliance process that require an agency to obtain an ATO and comply with additional requirements prior to adoption of new commercial software.
there is also rumor that the upcoming NIST RMF rev 5 will have a lot of detail about forcing vendors to provide their software supply chain.
IMO automation vi artifacts is the only way to go IF you want real security versus just compliance
Exactly. And not just security, but also regulatory compliance. Let's look at the recent VW case; software was written to get around regulations. Regulatory bodies could not inspect the software and could not find the reason for the regulatory discrepancy. After a year of work, they received information from the software designers themselves on how they defeated the inspection regime. This points to the necessity of understanding what every line of code does in your system for regulatory reasons. We already know we need this for security. But customers will need this, at least to certain degree, for the autonomous vehicles they ride in. Insurers will need it for the vehicles they insure. The list of stakeholders in complex autonomous systems running artificial intelligence algorithms in the functional safety domain is long. What are the tools that those stakeholders can use today?
Perhaps OpenChain is not the "solution" here, and I apologize if I'm off-topic, but OpenChain holds the keys to nascent and established best practices around introspection of complex software systems. We have code scanning tools and a way to package their results. We have a way to determine a one to one correspondence between license and software component. We have a way to determine the contents of git repos by examinging SHA sums. I think that there may be a way to build upon OpenChain to provide some degree of assurance that the contents of a given system are consistent with its attestations and claims to functionality, certification, etc. Yes, this may not be in the OpenChain mission, but where then is the best forum for this discussion?
This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.