--
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 13.03.2025 um 20:05 schrieb Scott Lewis via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>:
Thanks to Vicky for making this survey known. I would like to express support Vicky's observation
On 3/12/2025 10:51 AM, Victoria Risk via open-regulatory-compliance wrote:
<stuff deleted>
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've been...for a very long time...on both sides of this evaluation: i.e. as an OSS project lead for 25 years and as an evaluator of open source projects for large and small commercial sw and non-software companies, as well as non-profits and contributor to
other open source projects...including my own.
My observation is that consumers of most open source projects are sophisticated (at least the ones that I've worked with), much more so now than 25 years ago...but in general sophisticated about evaluating open source quality/trustworthiness/security/scalability/other
'ilities'.
IMO, Vicky's survey results also suggest that the things the OSS consumers recognize as being important for evaluating a project are heavily influenced by people/health of the project team...e.g. whether the original developers are available for support, whether
they are continuing with regular predictable releases, are innovating in the relevant technical space, whether active communication channels (docs and forums) are responded to, etc. This also fits with my own experience from both sides of the OSS consumer/producer
evaluation dance. For example, the first things I personally look at to evaluate an open source project is the recent commit history with changelog, api docs, release history, and recent forum activity.
I'm certainly *not* asserting that test suites, org/foundation affiliation, backing company, roadmap, CVE history, etc. are not important...they certainly are for many projects. But, it's obvious to me that the project team health is also very important to
many consumers.
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
_______________________________________________
open-regulatory-compliance
mailing list
open-regulatory-compliance@xxxxxxxxxxx
To
unsubscribe from this list, visit https://accounts.eclipse.org
|
