[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [open-regulatory-compliance] FYI UK Government report on OSS trust - gaps
|
Thanks Johannes.
SAG-CTR can register trust declarations for these digital objects, currently:
https://softwareassuranceguardian.com/SAGCTR_inquiry/getProductCategories
Using these "Trusted Label Identifiers":
https://softwareassuranceguardian.com/SAGCTR_inquiry/getLabelTypes
The presentation for NASA and DOE is specific to the US Government use case requirements to identify trustworthy software per OMB M-22-18 related to EO 14028 and the forthcoming US Coast Guard plans to create an "approved product list" (Trust Registry).
You are correct, the SCITT spec is still being developed. Business Cyber Guardian is a founding member of IETF SCITT and continues to contribute. Our plan is to update the SAG-CTR implementation to apply SCITT protocols when the spec settles, but in the mean time we continue to operate the SAG-CTR Trust Registry for people to use.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™
Risk always exists, but trust must be earned and awarded.™
https://businesscyberguardian.com/
Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
Tel: +1 978-696-1788
-----Original Message-----
From: Johannes Ebke <johannes.ebke@xxxxxx>
Sent: Wednesday, March 12, 2025 3:08 PM
To: dick@xxxxxxxxxxxxxxxxxxxxxxxxx; 'Open Regulatory Compliance Working Group' <open-regulatory-compliance@xxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] FYI UK Government report on OSS trust - gaps
Dick,
Thanks for the clarification. I was referring to the concrete SAG-CTR™ trust registry in 20250321-SAG-CTR.pptx , which you linked earlier, not to the SCITT draft of the abstract concept.
If there is a trust registry of projects or organizations, they could certainly use SCITT when it is finalized.
All the best
Johannes
On 12.03.25 19:35, Dick Brooks wrote:
> Johannes,
>
> A Trust Registry is not limited to just software product "trust
> declarations", with IETF SCITT a "signed statement" can be registered
> for any digital artifact, i.e. a WEB API for example can be listed in
> a "Trust Registry" or a Website;
>
> https://softwareassuranceguardian.com/SAGCTR_inquiry/getTrustedProduct
> Label?ProductID=8500146159E7695572930C2ED6D283A54C09D9BD60C0D3ACCF9ED3
> 6C70E1FAB7&html=1
>
> is the cybersecurity "trust label" for this API:
> https://softwareassuranceguardian.com/SAGCTR_inquiry/getProductCategor
> ies
>
>
> Here is the trust label for a Web site, https://www.interlynk.io/ :
> https://softwareassuranceguardian.com/SAGCTR_inquiry/getTrustedProduct
> Label?ProductID=66E6264EC2748FEF0048D17E9EA3157051B65C14274D99DC2E7389
> CD99CABD46&html=1
>
>
> There is no problem creating registering a trust label for an open source project or even a PURL descriptor:
>
>
> An IETF SCITT Trust Registry can handle any of these, easily - the "payloads" in a signed statement are opaque. But, they must comply with Registration Policies defined by the Transparency Service (Registry Operator).
> https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/
>
>
> Thanks,
>
> Dick Brooks
>
> Active Member of the CISA Critical Manufacturing Sector, Sector
> Coordinating Council – A Public-Private Partnership
>
> Never trust software, always verify and report! ™ Risk always exists,
> but trust must be earned and awarded.™
> https://businesscyberguardian.com/
> Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
> Tel: +1 978-696-1788
>
>
> -----Original Message-----
> From: open-regulatory-compliance
> <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Johannes
> Ebke via open-regulatory-compliance
> Sent: Wednesday, March 12, 2025 2:16 PM
> To: Open Regulatory Compliance Working Group
> <open-regulatory-compliance@xxxxxxxxxxx>
> Cc: Johannes Ebke <johannes.ebke@xxxxxx>
> Subject: Re: [open-regulatory-compliance] FYI UK Government report on
> OSS trust - gaps
>
> Hi Vicky,
>
> Thanks for the Link! It's an interesting dilemma from my admittedly
> not-as-expert-in-dns user perspective; but my guess (in addition to
> the final conclusions) is that *it is really hard to evaluate if a
> test suite, process, or self-certification is any good!*
>
> Tying this to the presentation that Dick (Brooks) will next Friday
> give to NASA/DOE; I as a user of Software personally would very much
> prefer to have a trust registry of /projects/ rather than /products/
> (product
> versions) as a first step; as this could evaluate all the best practices mentioned by Vicky, and also evaluate things I would see as central to me trusting organisations, e.g. incident history of the organization or their reactions to past incidents.
>
> All the best
> Johannes
>
>
>
> On 12.03.25 18:51, Victoria Risk via open-regulatory-compliance wrote:
>> Johannes, Florian -
>>
>> Sort of tangential to this topic, I did a small survey last summer
>> about what users look for in determining the risk level of an Open
>> source project, and the results were pretty disheartening. I was
>> approaching this from the perspective of an open source project,
>> wondering if we were putting our efforts into the things users cared
>> to look at. I am a fan of the OpenSSF Best Practices badge, and that approach, in general.
>> I was wondering if we should do more to expose, e.g. test results
>> summaries, that sort of thing.
>>
>> What I found was - there was basically no overlap between the things
>> we were doing to ensure quality and trustworthiness, and the things
>> the users were looking at to determine that.
>>
>> I like to think that our users are pretty sophisticated…. anyway,
>> here is a link to a summary for your amusement. (I was not asking
>> about SBOMS because we are providing source, and I can see I forgot
>> to even ask about code signing signature verification, but you get
>> the idea.) At any rate, I think a lot could be done just to better
>> educate users about what to look for.
>>
>> Vicky
>>
>>
>> preview.png
>> 2024_06_nanog_oss_risk
>> <https://www.isc.org/docs/2024_06_nanog_oss_risk.pdf>
>> PDF Document · 1.5 MB
>> <https://www.isc.org/docs/2024_06_nanog_oss_risk.pdf>
>>
>> <https://www.isc.org/docs/2024_06_nanog_oss_risk.pdf>
>>
>>> On Mar 12, 2025, at 1:31 PM, Johannes Ebke via open-regulatory-
>>> compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
>>>
>>> Hi everyone,
>>>
>>> Apologies to the list, this last message was supposed to go to
>>> Florian privately, therefore the language gap. If anyone else knows
>>> anything about existing trustworthiness comparisons between open-
>>> and
>>> closed- source software from different perspectives I would be interested.
>>>
>>> All the best
>>> Johannes Ebke
>>>
>>> On 12.03.25 18:28, Johannes Ebke via open-regulatory-compliance wrote:
>>>> Hallo und guten Abend,
>>>> Das finde ich prinzipiell auch sehr interessant! Ich würde mich
>>>> gern auf die Liste der Interessierten setzen falls das zustandekommt.
>>>> Interessant für mich wäre auch, wie man closed-source dann
>>>> bezüglich trustworthiness vergleichen (oder eben nicht vergleichen)
>>>> kann. Das wäre konkret wichtig um bei Kaufentscheidungen der
>>>> öffentlichen Hand was sinnvolles vorzugeben. Gibt es da auch schon Ansätze?
>>>> Viele Grüße
>>>> Johannes Ebke
>>>> On 12.03.25 15:15, Idelberger, Florian (IIWR) via open-regulatory-
>>>> compliance wrote:
>>>>> We have recently submitted a proposal for a research project would
>>>>> develop sth like this. Which would be open and accessible, if
>>>>> funded and deployed.
>>>>>
>>>>> --
>>>>> Dr. Florian Idelberger
>>>>>
>>>>>
>>>>> Karlsruher Institut für Technologie (KIT) Zentrum für Angewandte
>>>>> Rechtswissenschaft (ZAR) Institut für Informations- und
>>>>> Wirtschaftsrecht Vincenz-Prießnitz-Str. 3, D-76131 Karlsruhe
>>>>>
>>>>> E-Mail: florian.idelberger@xxxxxxx
>>>>>
>>>>> KIT - Universität des Landes Baden-Württemberg und nationales
>>>>> Forschungszentrum in der Helmholtz-Gemeinschaft
>>>>>
>>>>>> Am 12.03.2025 um 15:06 schrieb Dick Brooks via open-regulatory-
>>>>>> compliance <open-regulatory-compliance@xxxxxxxxxxx>:
>>>>>>
>>>>>> FYI:
>>>>>> A UK Government report on open source software contains some very
>>>>>> specific findings and recommendation to establish trustworthiness
>>>>>> in open source software:
>>>>>> https://www.securityweek.com/uk-government-report-calls-for-
>>>>>> stronger- open-source-supply-chain-security-practices/ <https://
>>>>>> www.securityweek.com/uk-government-report-calls-for-stronger-open
>>>>>> - source-supply-chain-security-practices/>
>>>>>> /4.1.3 Trust in Open-Source Software/ /Trust in OSS is a critical
>>>>>> concept//when adopting OSS components.How does one/ /come to
>>>>>> trust an OSS component?//More often than not, “there is no sound
>>>>>> basis/ /for trust in the Software Ecosystems (SECO) hubs”, with
>>>>>> trust being considered/ /“founded or unfounded” (Hou et al.,
>>>>>> 2022)./ // /Outside of academic papers,trustworthiness wasn’t
>>>>>> mentioned in any of the best/ /practices we reviewed//./ // /This
>>>>>> is a significant gap in the best practices landscape, as trust
>>>>>> plays a vital role/ /in adopting OSS components/.
>>>>>> This is precisely why a SCITT Trust Registry is essential, to
>>>>>> serve as a trust anchor for trustworthy software products with
>>>>>> specific cybersecurity labels providing justification for a
>>>>>> “trust score” in the registry, which the buying public can query
>>>>>> before buying a product.
>>>>>> The US Coast Guard is planning to implement a “Trust Registry” of
>>>>>> approved products, which limits which products can be installed
>>>>>> in IT and OT systems used by the US Coast Guard:
>>>>>> https://www.federalregister.gov/d/2025-00708/p-1047 <https://
>>>>>> www.federalregister.gov/d/2025-00708/p-1047>
>>>>>> I’m doing a presentation to the US NASA and the US Department of
>>>>>> Energy (DOE) on March 21 on this very topic of SCITT Trust
>>>>>> Registries to identify trustworthy products that have passed a
>>>>>> risk assessment and may be installed in IT and OT systems.
>>>>>> Trustworthiness of a product will be based on NIST SCRM best
>>>>>> practices contained in CISA’s Secure Software Acquisition
>>>>>> Guide,https:// cisa.gov/sag <https://cisa.gov/sag> Am happy to
>>>>>> share my March 21 slides with any that request them.
>>>>>> Thanks,
>>>>>> Dick Brooks
>>>>>> <image007.png><image008.png><image009.png>
>>>>>> /Active Member of the CISA Critical Manufacturing Sector,/
>>>>>> /Sector Coordinating Council – A Public-Private Partnership/
>>>>>> */Never trust software, always verify and report! <https://
>>>>>> reliableenergyanalytics.com/products>/*™
>>>>>> Risk always exists, but trust must be earned and awarded.™
>>>>>> https://businesscyberguardian.com/
>>>>>> <https://businesscyberguardian.com/>
>>>>>> Email:dick@xxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>> <mailto:dick@xxxxxxxxxxxxxxxxxxxxxxxxx>
>>>>>> Tel: +1 978-696-1788
>>>>>> _______________________________________________
>>>>>> open-regulatory-compliance mailing list
>>>>>> open-regulatory-compliance@xxxxxxxxxxx <mailto:open-regulatory-
>>>>>> compliance@xxxxxxxxxxx> To unsubscribe from this list,
>>>>>> visithttps://accounts.eclipse.org <https://accounts.eclipse.org/>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> open-regulatory-compliance mailing list
>>>>> open-regulatory-compliance@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://accounts.eclipse.org
>>>> _______________________________________________
>>>> open-regulatory-compliance mailing list
>>>> open-regulatory-compliance@xxxxxxxxxxx
>>>> To unsubscribe from this list, visit https://accounts.eclipse.org
>>>
>>> --
>>> Prof. Dr. Johannes Ebke - Fakultät für Informatik & Mathematik
>>> Department of Computer Science and Mathematics Hochschule München
>>> University of Applied Sciences Lothstrasse 64, 80335 München, R4.033
>>> T +49 89 1265-3756 https://www.cs.hm.edu |
>>> https://www.hm.edu/datenschutz/
>>>
>>> _______________________________________________
>>> open-regulatory-compliance mailing list
>>> open-regulatory-compliance@xxxxxxxxxxx
>>> To unsubscribe from this list, visit https://accounts.eclipse.org
>>
>>
>> _______________________________________________
>> open-regulatory-compliance mailing list
>> open-regulatory-compliance@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://accounts.eclipse.org
>
> --
> Prof. Dr. Johannes Ebke - Fakultät für Informatik & Mathematik
> Department of Computer Science and Mathematics Hochschule München
> University of Applied Sciences Lothstrasse 64, 80335 München, R4.033 T
> +49 89 1265-3756 https://www.cs.hm.edu |
> https://www.hm.edu/datenschutz/
>
>
--
Prof. Dr. Johannes Ebke - Fakultät für Informatik & Mathematik Department of Computer Science and Mathematics Hochschule München University of Applied Sciences Lothstrasse 64, 80335 München, R4.033 T +49 89 1265-3756 https://www.cs.hm.edu | https://www.hm.edu/datenschutz/
