[
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
|
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/getTrustedProductLabel?ProductID=8500146159E7695572930C2ED6D283A54C09D9BD60C0D3ACCF9ED36C70E1FAB7&html=1
is the cybersecurity "trust label" for this API:
https://softwareassuranceguardian.com/SAGCTR_inquiry/getProductCategories
Here is the trust label for a Web site, https://www.interlynk.io/ :
https://softwareassuranceguardian.com/SAGCTR_inquiry/getTrustedProductLabel?ProductID=66E6264EC2748FEF0048D17E9EA3157051B65C14274D99DC2E7389CD99CABD46&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/
