[
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
|
- From: Johannes Ebke <johannes.ebke@xxxxxx>
- Date: Wed, 12 Mar 2025 20:08:13 +0100
- Autocrypt: addr=johannes.ebke@xxxxxx; keydata= xsFNBF5fnu4BEADrsDQWLUMCFOAZUB662jOcGN4CyPB2kl1K0Dr+bnTm/gmOKQGsebdeoTRl y8SE+Xasvj9gq9aTgcP3L8nTmCDOBHXiXJi86MQrq0kvi+nXZUaDGGls/4qegoUvuE1I0HpJ UR194yq6JTZt+NvGpjQYll4sMdd9t3xZKBgKTKRO6oooaf0AE4tAR/sGR8nCwjkDrzf8tOjR YoFYWGthwYyrsM/fn1w9R5vCOU1L8iEwacafu97KL3mGJsgADW3jKxUCvu3R+1PH8B2CjQqu G/W8s5RnyhuBuSSFymtDk8vY09jbMFDv6dB3oEQz8+RQK9tz1a+oE/aobD8sloWhn7kpsFzz 9FSVacqhrLEP+iRFoUGA/2+30vxjMPk9m60NW951r96pOAnQv9zUUPIBzvcNsAFNiz+C7OJV p3+8QxkKMZzPJZTLjN1pdOLd2eQx1WxjyRvM0Ey3Qtvwq4b+JonorzYLE1GfN0APufM6S+mG qvCHOD+5+Tq39RSc3f309RI+8XCmEOV2655Egz1QbmyyhYTD60mpEJsgFsRLmcM9uLSD70gd Z4bBtMBav2rUUJwzTTp8AeMR86rsjnd3j9XAPK4mCQEriNzVnfZ5M8eJyWAfWhLy+DbUhJ3U 9+XhbTG96yU41OZd+XSXFXBlRV+5fXQIh/2CwldOgEa6Pq1EPQARAQABzSRKb2hhbm5lcyBF YmtlIDxqb2hhbm5lcy5lYmtlQGhtLmVkdT7CwZEEEwEKADsCGwMFCwkIBwIGFQoJCAsCBBYC AwECHgECF4AWIQSIM9Vu7MQ55Mm7zE6HdggzEZfcCAUCXmeJXQIZAQAKCRCHdggzEZfcCH+F D/9npEvg1Tsajm5vY+7KPWICJ53l01YpvXFnH15R/w1FNSyO2SW+t27z9FblRMqYBpIwMUKP 9k+c4tr3P2ES144R14Tz5tzRz0+CG+eznK6kGfpmyMPaei4i2SCxdYlB9BC1zaiu6pj0dJj6 Ij6W0yN7KFdAI4PT6/ExB8ElKCtmcykJ2+wybRFyR3YoDs0iMrv3EwWw2zF6Z1f3j1YBIB9h B9pDixF+vMLZ6kiiLStnPlAJJWXnG2QqML/vtx9+wyVR6b60rByfGLDcRieAWVA1jsxwE+wF 3iZB8wikpv2l6QxNLdNossf7LQ/fQt2yeo0E/E9ODXeZ9biBvxNuTwBVj652Qhk94qDEMaIb Tmg7C+96AYE8RMrRfm84SQz8orMMsnfkGaE5iHZK7gUzYg5ZxrJ72TlBllem5ZHF+pDob2u9 MqhtMtt6uCvkg8yugXi7O/DPqePbNP3aiz7m8r737HJ3RcKJyQrGm5S/lR3aQW55wuNejklL OBglb4mYywcFQor2/Aa6sg3Ct8TXtzImU9LVzurDrBiv7PkdAt4jtpOl/T2ODFrlJ7e1xQzF EhBwuYWLXJzbUISz67zX+U/nk/HMaTgKGd+DyRNTqKN5bgnZ8vOf8NrvpVsgFkdTsQyPrQOu 2cz0p5rXVCuE0s+5PCU53TG+cCfiWHmC/rEd1c7BTQReX57uARAAxKLIJKMr8WdtIyFU3Xse 3wYJJJzQrdK0lnmb80ut0wbX9xu72TFAtU8HzaHJW5LuAt/NbcavNKeziAQYRCWq7o0Mhkt6 owNPWVfp6wPrJFpTynbJtYL1J7qiUs9iJRyz5uQ1Kexz45nFfpLnGs6134ovM45m6UAjjAmP K2L0Rx3LafwpMT/NxCYt49DEqNhkBGJV4XbUanvxJUSIc2Z8tiw2gU/K5oIhqL5Q2PS/71Ft 8e1zy9A0pK7KlHhaju5ikoQDEgoDXaaa9jzTH8VZFQYWeDFpSSha3UgdX1K+eXR+R27Pk6ry BwDnyOuorg4t2AU1sCiDE9tmilbMOemOt6CWwXNdDXeP9ANsqITonvYKuGvjGGmL7XPc9TkB 13oKWwooCMHHSOVRgJthxH43BV/rSf80QO131MS1CnTPgdCsWJKVuDBdAh170/2i4luOEkJq C5sM5VgCIEO6LbWZke2dCjRbONBstfv8xTHrGdirFt9glE9afz/XTxsiOCCITbzlLradfnV4 JkwIhclfX0PeHa88bxxQ6jBwGlGEG1d/Q1tu0xhi1P6SsMWZb2FDqHgsFuwAOhEdUAiiz5k7 PL5uWcV9Do7JoHYWQ8cCuy3lK5ykig3SbydeEyQx5bd9XHDCBOWS4JbX3H+//dyABihH3n/V STwjboynxuDHlBEAEQEAAcLBdgQYAQoAIBYhBIgz1W7sxDnkybvMTod2CDMRl9wIBQJeX57u AhsMAAoJEId2CDMRl9wIID0QALkJtzgX3L+3GmGfbb1lzqV6Om9qFXtRTbyTcunuQNSEH0p5 Rs07SJCJzhJuMrv2/0lSCJBmZZyZQAmbThXXIjkUg0RWbb4QEMWSqCH+b2Zxx0ew9pcsLoZF mYo1BwlrVU8e+KBu3A4ZKj/Psm8iaUP+zhsHqvAtj9m0kNa6RXu8e7uORrIK6mapLu8sdasv w0skTMVT6yq53Olj66SyLf8yepRfeGqCrKglNbEN/zskl/+4EUfMX0zlrZ1IVtQbX5Y2zQy5 9qj/MXbW5rGALGi+lE7bnPQsDZ+hnUpMNOcfhxDjPZBkoqmAThI8BNBKvnddHkG+pdiwcfLY bhtacUaUKdQocfkLmpoRq1+gtkwSNcfjWJuut2BNc6LdtHmwamtjc1CYS8706Oz/muNBxexy yZVwxcgE+Bf9sWwlwonFQ5CMtklYjWb0I+IOUPypO6ynbYrgCu/4kMP1UeFpX9/3DjrpAcDK ZJx6FPUGPUhFPsv7uezqlfwQpLHS17gmLptltQeuaWgJ/0qPmpKBdXQ6AgG0QjUZ+A3MYZBU X3wPqLxKsqUJ4bUzHdGN0y7xnGRRfRmKbIh6yfm3UMGM/imyGXlGL+orDCKO6ygs9Oq7Z5F9 rnhrmRum+zrJNtlu1Y+jhmsdqmHH8KHXgGTonXgjPXpzlk3wK4YT18rTJdXb
- Delivered-to: open-regulatory-compliance@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/open-regulatory-compliance/>
- List-help: <mailto:open-regulatory-compliance-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/open-regulatory-compliance>, <mailto:open-regulatory-compliance-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/open-regulatory-compliance>, <mailto:open-regulatory-compliance-request@eclipse.org?subject=unsubscribe>
- User-agent: Mozilla Thunderbird
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/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/
--
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/
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature