SlideShare a Scribd company logo
An Introduction to the
Core Infrastructure
Initiative (CII)
Best Practices Badge
David A. Wheeler, dwheeler AT linuxfoundation DOT org
Director of Open Source Supply Chain Security
Linux Foundation
2020-08-30
0
Antitrust Policy Notice
 Linux Foundation meetings involve participation by industry competitors,
and it is the intention of the Linux Foundation to conduct all of its activities
in accordance with applicable antitrust and competition laws. It is therefore
extremely important that attendees adhere to meeting agendas, and be
aware of, and not participate in, any activities that are prohibited under
applicable US state, federal or foreign antitrust and competition laws.
 Examples of types of actions that are prohibited at Linux Foundation
meetings and in connection with Linux Foundation activities are described
in the Linux Foundation Antitrust Policy available at
http://www.linuxfoundation.org/antitrust-policy. If you have questions about
these matters, please contact your company counsel, or if you are a
member of the Linux Foundation, feel free to contact Andrew Updegrove of
the firm of Gesmer Updegrove LLP, which provides legal counsel to the
Linux Foundation.
1
See: https://www.linuxfoundation.org/antitrust-policy/
Heartbleed
 In 2014, Heartbleed vulnerability found in OpenSSL
 Highlighted OSS* projects don’t always follow widely
accepted practices, which results in avoidable problems
2
*OSS=Open source software. OSS is licensed to its users in a way that allows them to run the program for any purpose, study and
modify the program, and freely redistribute copies of either the original or modified program (without royalties to original author, etc.)
OSS project practices matter!
 It is not true that “all OSS is insecure” … or that
“all OSS is secure”
 It is not true that “all OSS is poor quality” … or
that “all OSS has excellent quality”
 OSS tends to be more secure & higher quality if
the project follows good practices
 Good people necessary, but insufficient
 Both creators & users of OSS want good results
 What are those good practices?
 How can we encourage projects to follow them?
 How can anyone know if they’re being followed?
3
CII* Best Practices Badge
 Identified best practices for OSS projects
 For production of OSS**
 Based on practices of well-run OSS projects
 Increase likelihood of better quality & security
 Criteria designed for any OSS project
 Web application: OSS projects self-certify
 If OSS project meets criteria, it gets a badge
 No cost
 Self-certification mitigated by automation, public
display of answers (for criticism), spot-checks, and
can be overridden if false
4
** for receiving OSS, esp. license compliance, see OpenChain* CII = Core Infrastructure Initiative
Who created & runs the Badging Project?
 Linux Foundation (LF)
 “dedicated to building sustainable ecosystems around
open source projects to accelerate technology
development and industry adoption”
 nonprofit mutual benefit corporation, 501(c)(6)
 Linux kernel, JS Foundation, Cloud Native Computing
Foundation (CNCF), R Consortium, LF Energy, …
 Core Infrastructure Initiative (CII) organized by LF
 “to fund and support critical elements of the global
information infrastructure”
 Badging project is an OSS project created by CII
 Yes, we earn our own badge 
5
BadgeApp: Home page
6
To get your OSS project a badge, go to
https://bestpractices.coreinfrastructure.org/
Some OSS projects with a best practices badge
7
GNU Make
CII badges are increasingly getting adopted!
8Source: https://bestpractices.coreinfrastructure.org/project_stats
as of 2020-07-02
All
projects
Projects
with non-
trivial
progress
Over 3,200 projects participating!
450 passing!
General availability May 2016
Badge levels
 Three badge levels (passing, silver, gold)
 For higher levels, must meet previous level
 Passing:
 Captures what well-run projects typically already do
 Not “they should do X, but no one does that”
 66 criteria in 6 groups:
 Basics, Change Control, Reporting, Quality, Security,
Analysis
 Silver: Harder but possible for 1-person projects
 Gold requires multiple developers
 bus factor > 1*, 2-person review
9
Source: https://github.com/coreinfrastructure/best-practices-badge/
blob/master/doc/criteria.md
Badge criteria developed to be reasonable!
 Relevant
 Attainable by typical OSS projects (esp. passing)
 Clear
 Include security-related criteria (but not only those)
 Consensus of developers & users
 Criteria & web app developed as OSS project
 Built on existing work, e.g., Karl Fogel’s Producing Open
Source Software
 Not hypocritical
 Our web app must get its own badge!
10
Worked with several projects, such as the
Linux kernel & curl, to test criteria validity
Non-requirements
 Does NOT require any specific technology, product, or
service
 Does NOT require or forbid any particular programming
language
 Sometimes includes tips
 Exception: Expect projects to have a web page with TLS
 NEVER requires proprietary software or service
 You may use or depend on it
 Does NOT cost anything
 Does NOT “take over your project”
 Does NOT require doing everything immediately
 Some projects have immediately earned a badge
 Most projects try for a badge, find some things missing, &
gradually work to fix those issues
11
Sample passing badge criteria (yes, they’re
reasonable)
 “The project website MUST succinctly describe what the software
does (what problem does it solve?).” [description_good]
 “The project MUST use at least one automated test suite that is
publicly released as FLOSS (this test suite may be maintained as a
separate FLOSS project).” [test]
 “At least one static code analysis tool MUST be applied to any
proposed major production release of the software before its
release, if there is at least one FLOSS tool that implements this
criterion in the selected language.” [static_analysis]
 “The project sites (website, repository, and download URLs) MUST
support HTTPS using TLS.” [sites_https]
 “The project MUST publish the process for reporting vulnerabilities
on the project site.” [vulnerability_report_process]
12*FLOSS=Free/Libre/Open source software
Available in English, Chinese, French, German, Japanese, & Russian
Each criterion has a unique id; each id shown here in brackets
Badge scoring system
 To obtain a badge, all:
 MUST and MUST NOT criteria (42/66*) must be met
 SHOULD (10/66*) met, OR unmet with justification
 Users can see those justifications & decide if that’s enough
 SUGGESTED (14/66*) considered (met or unmet)
 People don’t like admitting they didn’t do something
 In some cases, URL required in justification (to point
to evidence; 8/66* require this)
13
* For the passing badge
Miscellaneous info
 Badging web application has automation
 Automatically examines projects on creation/edits
 Fills in some info & rejects obviously incorrect
 Some larger organizations require badging
 Open Network Automation Platform (ONAP)
 Cloud Native Computing Foundation (CNCF)
graduation requirement
 Supports easy display of badge info
 GitHub-style badge for README
 REST API & CORS for easy display of info
14
For details, see (ONAP) https://wiki.onap.org/display/DW/CII+Badging+Program
(CNCF graduation) https://www.cncf.io/projects/graduation-criteria/
(Dashboard example) https://landscape.cncf.io/selected=kubernetes
Sample impacts of CII badge process
 OWASP ZAP (web app scanner)
 Simon Bennetts: “[it] helped us improve ZAP quality… [it] helped
us focus on [areas] that needed most improvement.”
 Change: Significantly improved automated testing
 CommonMark (Markdown in PHP) changes:
 TLS for the website (& links from repository to it)
 Publishing the process for reporting vulnerabilities
 JSON for Modern C++
 “I really appreciate some formalized quality assurance which
even hobby projects can follow.”
 Change: Added explicit mention of how to privately report errors
 Change: Added a static analysis check to continuous integration
script
15Source: https://github.com/coreinfrastructure/best-practices-badge/wiki/Impacts
Conclusions
 Involved in an OSS project? Get a badge!
 Start here: https://bestpractices.coreinfrastructure.org
 Don’t need to do “everything at once” – just start!
 Questions? Email or create an issue
 Prefer using OSS from projects using best practices
 They are trying to “do the right thing”
 You want to use OSS from projects like that!
 CII best practices badge helps identify those projects
 Criteria need additions/refinements?
 Let us know, we’re also an OSS project
 More info:
 https://github.com/coreinfrastructure/best-practices-badge
 https://github.com/coreinfrastructure/best-practices-
badge/wiki/Videos
16
Get or check on badges at:
https://bestpractices.coreinfrastructure.org
Backup
17
Many projects working towards silver & gold
18
Progress
to silver
Progress
to gold
Source: https://bestpractices.coreinfrastructure.org/project_stats
?type=uncommon as of 2020-07-02
112 projects are halfway or better,
including 16 projects with silver
27 projects are halfway or better,
including 6 projects with gold
Some communities encouraging badges
 Cloud Native Computing Foundation (CNCF)*
 Maturity levels: Sandbox → incubating → graduated
 For graduated level must “have achieved and
maintained a CII Best Practices Badge.”
 Containerd graduated, has passing badge
 R community discussing recommending badges
 2018 survey:
 90% believe badge will provide value to the R community’s
package developers or package users
 77% saying it has benefit for both developers and users
 74% would be willing to try it
 Multiple R packages tried it out & began working
towards badges as part of discussion
 DBI passing
 Close to passing include ggplot2, covr, dodgr, netReg
19
Sources: CNCF Graduation Criteria v1.2
https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc
“Should R Consortium Recommend CII Best Practices Badge for R Packages: Latest Survey Results” https://www.r-
consortium.org/blog/2018/07/26/should-r-consortium-recommend-cii-best-practices-badge-for-r-packages-latest-survey-results
Remote access enabled
 Can easily embed current badge image
 <img src="https://bestpractices.coreinfrastructure.
org/projects/PROJECT_NUMBER/badge">
 Easily shows current state on GitHub, etc.
 REST API enables easy JSON data access
 Including project database download for analysis
 See https://github.com/coreinfrastructure/best-
practices-badge/blob/master/doc/api.md
 Cross Origin Resource Sharing (CORS)
 Enables data access from client-side JavaScript
 E.g., for fancy client-side dashboards
20
Example: CNCF landscape
 CNCF landscape <https://landscape.cncf.io/>
easily accesses badge data
21
Sample impacts of CII badge process (1 of 2)
 OWASP ZAP (web app scanner)
 Simon Bennetts: “[it] helped us improve ZAP quality… [it] helped us
focus on [areas] that needed most improvement.”
 Change: Significantly improved automated testing
 CommonMark (Markdown in PHP) changes:
 TLS for the website (& links from repository to it)
 Publishing the process for reporting vulnerabilities
 OPNFV (open network functions virtualization)
 Change: Replaced no-longer-secure crypto algorithms
 JSON for Modern C++
 “I really appreciate some formalized quality assurance which even
hobby projects can follow.”
 Change: Added explicit mention how to privately report errors
 Change: Added a static analysis check to continuous integration script
22Source: https://github.com/coreinfrastructure/best-practices-badge/wiki/Impacts
Sample impacts of CII badge process (2 of 2)
 BRL-CAD
 Probably would have taken an hour uninterrupted, getting to 100%
passing was relatively easy
 Website certificate didn’t match our domain, fixed
 POCO C++ Libraries
 “... thank you for setting up the best practices site. It was really helpful
for me in assessing the status…”
 Updated the CONTRIBUTING.md file to include a statement on
reporting security issues
 Updated the instructions for preparing a release in the Wiki to include
running clang-analyzer
 Enabled HTTPS for the project website
 GNU Make
 HTTPS. Convinced Savannah to support HTTPS for repositories (it
supported HTTPS for project home pages)
23Source: https://github.com/coreinfrastructure/best-practices-badge/wiki/Impacts
Sample clarifications
 vulnerabilities_fixed_60_days (PR #1188)
 “There MUST be no unpatched vulnerabilities of medium or high
severity that have been publicly known for more than 60 days.”
 Added: “… this badge criterion, like other criteria, applies to the
individual project. Some projects are part of larger umbrella… An
individual project often cannot control the rest, but an individual
project can work to release a vulnerability patch in a timely way.”
 hardened_site (PR #1187)
 “The project website, repository (if accessible via the web), and
download site (if separate) MUST include key hardening
headers… [GitHub is known to meet this]”
 Added: “Static web sites with no ability to log in via the web
pages may omit the CSP and X-XSS-Protection HTTP
hardening headers, because in that situation those headers are
less effective.”
24
Most common challenges for getting a badge
 All projects 90%+ but not passing (2019-03-07)
 265 projects. MUST with Unmet or “?” => Top 10 challenges:
25
# Criterion %miss Old rank#
1 vulnerability_report_process 21% 1
2 tests_are_added 17% 3
3 vulnerability_report_private 15% 4
4 know_secure_design 13% 9
5 vulnerabilities_fixed_60_days 13% 24
6 test_policy 13% 5
7 know_common_errors 13% 7
8 static_analysis 11% 8
9 static_analysis_fixed 11% 21
10 sites_https 9% 2
This data is as of
2019-03-07,
old rank from
2017-09-06
Analysis
Vulnerability
reporting
Tests
HTTPS
Know
secure
development
Mostly same challenges as 2017-09-06. HTTPS becoming less of a problem,
dropped from #2 to #10. Unclear why fixing things has become bigger problem..!
Fixing
Tests
 Criteria
 #1 The project MUST have evidence that such tests are being
added in the most recent major changes to the project.
[tests_are_added]
 #4 The project MUST have a general policy (formal or not) that
as major new functionality is added, tests of that functionality
SHOULD be added to an automated test suite. [test_policy]
 Automated testing is important
 Quality, supports rapid change, supports updating dependencies
when vulnerability found
 No coverage level required – just get started
26
Vulnerability reporting
 Criteria
 #2 “The project MUST publish the process for reporting
vulnerabilities on the project site.” [vulnerability_report_process]
 #8 “If private vulnerability reports are supported, the project
MUST include how to send the information in a way that is kept
private.” [vulnerability_report_private]
 Just tell people how to report!
 In principle easy to do – but often omitted
 Projects need to decide how
27
HTTPS
 #3 “The project sites (website, repository, and download
URLs) MUST support HTTPS using TLS.” [sites_https]
 Details:
 You can get free certificates from Let's Encrypt.
 Projects MAY implement this criterion using (for example)
GitHub pages, GitLab pages, or SourceForge project pages.
 If you are using GitHub pages with custom domains, you MAY
use a content delivery network (CDN) as a proxy to support
HTTPS.
 We’ve been encouraging hosting systems to support
HTTPS
28
Analysis
 #5 “At least one static code analysis tool MUST be
applied to any proposed major production release of the
software before its release, if there is at least one
FLOSS tool that implements this criterion in the selected
language.” [static_analysis]
 A static code analysis tool examines the software code (as
source code, intermediate code, or executable) without
executing it with specific inputs.
 #6 “All medium and high severity exploitable
vulnerabilities discovered with dynamic code analysis
MUST be fixed in a timely way after they are confirmed.”
[dynamic_analysis_fixed]
 Early versions didn’t allow “N/A”; this has been fixed.
29
Know secure development
 Criteria
 #8 “The project MUST have at least one primary developer who
knows how to design secure software.” [know_secure_design]
 #9 “At least one of the primary developers MUST know of
common kinds of errors that lead to vulnerabilities in this kind of
software, as well as at least one method to counter or mitigate
each of them.” [know_common_errors]
 Specific list of requirements given – doesn’t require
“know everything”
 Perhaps need short “intro” course material?
30
Documentation
 #10 “The project MUST include reference documentation that
describes its external interface (both input and output).”
[documentation_interface]
 Some OSS projects have good documentation – but some do not
31
Application security: Using an assurance case
 We want applications to be generally secure
 However, security:
 Can’t be directly measured (“how many kilograms”)
 Is an emergent property (totality of components)
 Is often a negative property (“never does X”)
 How can you know “we’ve done enough”?
 “Did long list of things” doesn’t provide confidence
 How do you know those were the right things?
 Must be able to justify & refine later
 Must avoid breaking the bank
 Useful approach: an “assurance case”
 Starts with the overall goal
 Repeatedly break the goal into smaller parts
 Not complicated – keeps track of what needs to be done
 Pattern we’ve used may be useful to you too!
32
Assurance case: Top level (figure 1)
33
Assets &
threat actors
identified &
addressed
System is adequately
secure against moderate
threats
Confidentiality Integrity Availability
Security implemented in
all software
development processes
Security requirements
identified and met by
functionality
Security implemented by
software life cycle processes
See next figure
Access
control
Identifi-
cation
Authenti-
cation
Authori-
zation
Fill in the more specific
requirements, then the
arguments of why they are
met (design, implementation,
verification,…) – but
avoid repetition
Assurance case: Next level (partial figure 2)
34
…
Not a waterfall-
These are
processes, not
phases
Life cycle technical processes (figure 2)
35
Verification:
many tools
Design:
Esp.
attack
model +
Saltzer
& Schr-
oeder
principle
s
Security in implementation (figure 3)
36
All
OWASP
top 10
(2013 &
2017)
countered
Entire most-
relevant security
guide applied
Hardening
applied
Hardened
outugoing HTTP
headers, including
restrictive CSP
Incoming
rate
limits
Force
HTTPS,
including
via HSTS
CSRF
token
harden-
ing
Outgoing
email
rate limit
1. Injection (incl.
SQL injection)
2. Auth &
session
3. XSS
4. Insecure
object references
5. Security
misconfiguration
6. Sensitive data
exposure
7. Missing
access control
8. CSRF
9. Known
vulnerabilities
10. Unvali-
dated
redirect/fwd
See securely reuse
(supply chain)
See security guide applied
Most implementation
vulnerabilities are due to
common types of
implementation errors or
common misconfigurations,
so countering them greatly
reduces security risks
Reduce/eliminate
impact if defect exists
All of the most
common important
implementation
vulnerability types
(weaknesses)
countered
All of the most common
known security-relevant
misconfiguration errors
countered
11. XXE (2017 A4)
12. Insecure
deserialization
(2017 A8)
13. Insufficient
logging and
,onitoring (2017
A10)
Encrypted
email
addresses
Cookie
limits
Securely
reuse
Review before use
Get authentic
version
Use package
manager
Security in
implementation
OWASP
Top 10 Web
hardening,
esp. CSP
Reuse/
Supply
chain
BadgeApp dependencies and security
 Tiny amount of new code in our system…
 Because almost all code is reused
 Direct dependencies = 75 gems
 Direct AND indirect dependencies = 197 gems
 Plus OS, language runtime, RDBMS, etc.
 Today a key security concern for most projects is
vulnerabilities through their dependencies
 Minimize dependencies, ask them to minimize their run-time
dependencies, sanity check of direct dependencies
 Package manager: Track what we have, trivially update
packages
 Dependency tools*: detect & report packages with known
vulnerabilities (GitHub + bundle audit)
 Thorough automated tests: enable quick update, test, & ship to
production (we have 100% coverage)
 Other measures, esp. hardening (such as CSP), reduce risk in
meantime
37
* Origin analysis / software composition analysis tools
Got on Hacker News (HN)!
 Badge-related post got on Hacker News front page on 2018-10-06
 “Certainly not knocking on the badge or the practices…I just found it
amusing that PHP often gets a bad rap, but then shows up at the top of
the listed projects for objectively good development practices.” -
reindeerer
 “I just found and read through the criteria list. It's mind-bogglingly
exhaustive, but in a very good way, and an excellent catalyst for
maintainable, secure software. I'd regard it as universally applicable
to any and all code.” – exikyut
 “Lots of self-proclaimed ‘experts’ love to say ‘do X and Y and Z and you
will be successful because these are best practices’, but it's all a bunch
of snake oil… ‘Best practices are best not practiced.’” – userbinator,
dissenting, but then downvoted & replied to…
 “Best practices are a bit like good genes. [They’re] by no means a
guarantee of success, fame, glory and riches, but damn if they don't
make things easier.” - reindeerer
 “I see absolutely nothing dogmatic or cargo cult about the
recommendations they make. They are completely sensible, and a
decent guideline for improving the technical support infrastructure of a
project.” - throwaway2048
38Source: https://news.ycombinator.com/item?id=18157494
Natural languages supported
 English (en)
 Chinese (Simplified) / 简体中文 (zh-CN)
 French / Français (fr)
 German / Deutsch (de)
 Japanese / 日本語 (ja)
 Russian / Русский (ru)
39
Even if you can’t understand the detailed justifications,
you can see the criteria & claimed answers
Our sincere
thanks to all
the hard-working
translators!!
Open source software
 OSS: software licensed to users with these freedoms:
 to run the program for any purpose,
 to study and modify the program, and
 to freely redistribute copies of either the original or modified
program (without royalties to original author, etc.)
 Original term: “Free software” (confused with no-price)
 Other synonyms: libre sw, free-libre sw, FOSS, FLOSS
 Antonyms: proprietary software, closed software
 Widely used; OSS #1 or #2 in many markets
 “… plays a more critical role in the DoD than has generally been
recognized.” [MITRE 2003]
 OSS almost always commercial by law & regulation
 Software licensed to general public & has non-government use
 commercial software (in US law, per 41 USC 403)
40
Statistics about the criteria themselves
41
Level Total
active
MUST SHOULD SUGG-
ESTED
Allow
N/A
Met
justifi-
cation or
URL
required
Includes
details
New at
this level
Passing 66 42 10 14 27 9 48 66
Silver 55 44 10 1 39 54 38 48
Gold 23 21 2 0 9 21 15 14
Source: https://bestpractices.coreinfrastructure.org/criteria
as of 2017-09-10
There are not a lot of gold criteria, but they’re challenging.
Passing criteria categories and examples (1)
1. Basics
 The software MUST be released as FLOSS*. [floss_license]
 It is SUGGESTED that any required license(s) be approved by
the Open Source Initiative (OSI). [floss_license_osi]
2. Change Control
 The project MUST have a version-controlled source repository
that is publicly readable and has a URL. [repo_public]
 Details: The URL MAY be the same as the project URL. The project
MAY use private (non-public) branches in specific cases while the
change is not publicly released (e.g., for fixing a vulnerability before
it is revealed to the public).
3. Reporting
 The project MUST publish the process for reporting
vulnerabilities on the project site. [vulnerability_report_process]
42
*FLOSS=Free/Libre/Open Source Software
Passing criteria categories and examples (2)
4. Quality
 If the software requires building for use, the project MUST
provide a working build system that can automatically rebuild
the software from source code. [build]
 The project MUST have at least one automated test suite that
is publicly released as FLOSS (this test suite may be
maintained as a separate FLOSS project). [test]
 The project MUST have a general policy (formal or not) that as
major new functionality is added, tests of that functionality
SHOULD be added to an automated test suite. [test_policy]
 The project MUST enable one or more compiler warning flags,
a "safe" language mode, or use a separate "linter" tool to look
for code quality errors or common simple mistakes, if there is
at least one FLOSS tool that can implement this criterion in the
selected language. [warnings]
43
Passing criteria categories and examples (3)
5. Security
 At least one of the primary developers MUST know of common
kinds of errors that lead to vulnerabilities in this kind of
software, as well as at least one method to counter or mitigate
each of them. [know_common_errors]
 The project's cryptographic software MUST use only
cryptographic protocols and algorithms that are publicly
published and reviewed by experts. [crypto_published]
 The project MUST use a delivery mechanism that counters
MITM attacks. Using https or ssh+scp is acceptable.
[delivery_mitm]
 There MUST be no unpatched vulnerabilities of medium or
high severity that have been publicly known for more than 60
days. [vulnerabilities_fixed_60_days]
44
Passing criteria categories and examples (4)
6. Analysis
 At least one static code analysis tool MUST be applied to any
proposed major production release of the software before its
release, if there is at least one FLOSS tool that implements this
criterion in the selected language… [static_analysis]
 It is SUGGESTED that the {static code analysis} tool include
rules or approaches to look for common vulnerabilities in the
analyzed language or environment.
[static_analysis_common_vulnerabilities]
 It is SUGGESTED that at least one dynamic analysis tool be
applied to any proposed major production release of the
software before its release. [dynamic_analysis]
45
Silver: Sample criteria (1 of 2)
 The project MUST clearly define and document its project
governance model (the way it makes decisions, including key roles).
[governance]
 The project MUST be able to continue with minimal interruption if
any one person is incapacitated or killed… [you] MAY do this by
providing keys in a lockbox and a will providing any needed legal
rights (e.g., for DNS names). [access_continuity]
 The project MUST have FLOSS automated test suite(s) that provide
at least 80% statement coverage if there is at least one FLOSS tool
that can measure this criterion in the selected language.
[test_statement_coverage80]
 The project MUST automatically enforce its selected coding style(s)
if there is at least one FLOSS tool that can do so in the selected
language(s). [coding_standards_enforced]
 The project MUST implement secure design principles (from
"know_secure_design"), where applicable…
[implement_secure_design] 46
Silver: Sample criteria (2 of 2)
 The project results MUST check all inputs from potentially untrusted
sources to ensure they are valid (a whitelist), and reject invalid
inputs, if there are any restrictions on the data at all.
[input_validation]
 The project MUST cryptographically sign releases of the project
results intended for widespread use, and there MUST be a
documented process explaining [how to] obtain the public signing
keys and verify the signature(s)… [signed_releases]
 The project MUST provide an assurance case that justifies why its
security requirements are met. [It MUST…] [assurance_case]
 The project MUST use at least one static analysis tool … to look for
common vulnerabilities… , if there is at least one FLOSS tool that
can… [static_analysis_common_vulnerabilities]
 Projects MUST monitor or periodically check their external
dependencies (including convenience copies) to detect known
vulnerabilities, and fix exploitable vulnerabilities or verify them as
unexploitable. [dependency_monitoring] 47
Gold: Sample criteria
 The project MUST require two-factor authentication (2FA) for
developers for changing a central repository or accessing sensitive
data (such as private vulnerability reports)… [require_2FA]
 The project MUST have at least 50% of all proposed modifications
reviewed before release by a person other than the author…
[two_person_review]
 The project MUST have a "bus factor" of 2 or more. [bus_factor]
 The project MUST have a reproducible build… [build_reproducible]
 The project MUST apply at least one dynamic analysis tool to any
proposed major production release of the software before its release.
[dynamic_analysis]
 The project MUST have performed a security review within the last 5
years. This review MUST consider the security requirements and
security boundary. [security_review]
 Hardening mechanisms MUST be used in the software produced by the
project so that software defects are less likely to result in security
vulnerabilities. [hardening]
48
Key URLs
 CII best practices badge (get a badge):
 https://bestpractices.coreinfrastructure.org/
 CII best practices badge project:
 https://github.com/coreinfrastructure/best-practices-
badge
49
My thanks to the many who reviewed or helped develop the badging criteria and/or the software to implement it. This includes:
Mark Atwood, Tod Beardsley, Doug Birdwell, Alton(ius) Blom, Hanno Böck, enos-dandrea, Jason Dossett, David Drysdale,
Karl Fogel, Alex Jordan (strugee), Sam Khakimov, Greg Kroah-Hartman, Dan Kohn, Charles Neill (cneill), Mark Rader, Emily
Ratliff, Tom Ritter, Nicko van Someren, Daniel Stenberg (curl), Marcus Streets, Trevor Vaughan, Dale Visser, Florian Weimer
Involved in OSS?
 If you lead an OSS project, what you do matters!
 People depend on the software you create
 The practices you apply affect the result
 Secure or quality software is not an accident
 Please try to get a badge, & show when you have it
 If you’re considering using an OSS project
 Check on the project – should you use it?
50
Release of presentation
 This presentation is released under Creative Commons Attribution 3.0 or
later (CC-BY-3.0+)
 Credits
 Older versions were developed by the Institute for Defense Analyses (IDA);
thank you!
51

More Related Content

What's hot

OpenChain Automation Case Study - September to December 2021
OpenChain Automation Case Study - September to December 2021OpenChain Automation Case Study - September to December 2021
OpenChain Automation Case Study - September to December 2021
Shane Coughlan
 
OpenChain Automotive Work Group Meeting #2 - Lyon
OpenChain Automotive Work Group Meeting #2 - LyonOpenChain Automotive Work Group Meeting #2 - Lyon
OpenChain Automotive Work Group Meeting #2 - Lyon
Shane Coughlan
 
OpenChain Webinar #10 - Joint Development Foundation - 2020-08-17
OpenChain Webinar #10 - Joint Development Foundation - 2020-08-17OpenChain Webinar #10 - Joint Development Foundation - 2020-08-17
OpenChain Webinar #10 - Joint Development Foundation - 2020-08-17
Shane Coughlan
 
Open Source at Scania
Open Source at ScaniaOpen Source at Scania
Open Source at Scania
Shane Coughlan
 
Bosch: AN UPDATE ON OUR ACTIVITIES IN AUTOMATING OSS COMPLIANCE: A WORKING SH...
Bosch: AN UPDATE ON OUR ACTIVITIES IN AUTOMATING OSS COMPLIANCE: A WORKING SH...Bosch: AN UPDATE ON OUR ACTIVITIES IN AUTOMATING OSS COMPLIANCE: A WORKING SH...
Bosch: AN UPDATE ON OUR ACTIVITIES IN AUTOMATING OSS COMPLIANCE: A WORKING SH...
Shane Coughlan
 
OpenChain: How to manage OSS licenses for CI/CD development
OpenChain: How to manage OSS licenses for CI/CD developmentOpenChain: How to manage OSS licenses for CI/CD development
OpenChain: How to manage OSS licenses for CI/CD development
Shane Coughlan
 
Using SW360 for OSS Compliance Management Process - A Toshiba Case Study for ...
Using SW360 for OSS Compliance Management Process - A Toshiba Case Study for ...Using SW360 for OSS Compliance Management Process - A Toshiba Case Study for ...
Using SW360 for OSS Compliance Management Process - A Toshiba Case Study for ...
Shane Coughlan
 
Strategies to Reap the Benefits of Software Patents in an Open Source Softwar...
Strategies to Reap the Benefits of Software Patents in an Open Source Softwar...Strategies to Reap the Benefits of Software Patents in an Open Source Softwar...
Strategies to Reap the Benefits of Software Patents in an Open Source Softwar...
Black Duck by Synopsys
 
What in the World is Going on at The Linux Foundation?
What in the World is Going on at The Linux Foundation?What in the World is Going on at The Linux Foundation?
What in the World is Going on at The Linux Foundation?
Black Duck by Synopsys
 
Giving Everyone Access To Open Source Best Practices: The OpenChain Curriculum
Giving Everyone Access To Open Source Best Practices: The OpenChain CurriculumGiving Everyone Access To Open Source Best Practices: The OpenChain Curriculum
Giving Everyone Access To Open Source Best Practices: The OpenChain Curriculum
Shane Coughlan
 
Open source code
Open source codeOpen source code
Open source code
Intetics
 
Managing the Software Supply Chain: Policies that Promote Innovation While Op...
Managing the Software Supply Chain: Policies that Promote Innovation While Op...Managing the Software Supply Chain: Policies that Promote Innovation While Op...
Managing the Software Supply Chain: Policies that Promote Innovation While Op...
FINOS
 
Samsung & The Path to Open Source Leadership (OBC)
Samsung & The Path to Open Source Leadership (OBC)Samsung & The Path to Open Source Leadership (OBC)
Samsung & The Path to Open Source Leadership (OBC)
Samsung Open Source Group
 
Webinar–The 2019 Open Source Year in Review
Webinar–The 2019 Open Source Year in ReviewWebinar–The 2019 Open Source Year in Review
Webinar–The 2019 Open Source Year in Review
Synopsys Software Integrity Group
 
Why is Open Source Important to Samsung and What Are We Doing About It?
Why is Open Source Important to Samsung and What Are We Doing About It?Why is Open Source Important to Samsung and What Are We Doing About It?
Why is Open Source Important to Samsung and What Are We Doing About It?
Samsung Open Source Group
 
SFScon 2020 - Davide Ricci - FOSS management and license compliance must come...
SFScon 2020 - Davide Ricci - FOSS management and license compliance must come...SFScon 2020 - Davide Ricci - FOSS management and license compliance must come...
SFScon 2020 - Davide Ricci - FOSS management and license compliance must come...
South Tyrol Free Software Conference
 
Licensing in Composite Open Source Projects
Licensing in Composite Open Source ProjectsLicensing in Composite Open Source Projects
Licensing in Composite Open Source Projects
Protecode
 
2011 NASA Open Source Summit - Forge.mil
2011 NASA Open Source Summit - Forge.mil2011 NASA Open Source Summit - Forge.mil
2011 NASA Open Source Summit - Forge.mil
NASA Open Government Initiative
 
Licensing in Composite Projects
Licensing in Composite ProjectsLicensing in Composite Projects
Licensing in Composite Projects
Tiberius Forrester
 
Open Source In Enterprises Apache2009 Beijing Jack Cai
Open Source In Enterprises Apache2009 Beijing Jack CaiOpen Source In Enterprises Apache2009 Beijing Jack Cai
Open Source In Enterprises Apache2009 Beijing Jack Cai
OpenSourceCamp
 

What's hot (20)

OpenChain Automation Case Study - September to December 2021
OpenChain Automation Case Study - September to December 2021OpenChain Automation Case Study - September to December 2021
OpenChain Automation Case Study - September to December 2021
 
OpenChain Automotive Work Group Meeting #2 - Lyon
OpenChain Automotive Work Group Meeting #2 - LyonOpenChain Automotive Work Group Meeting #2 - Lyon
OpenChain Automotive Work Group Meeting #2 - Lyon
 
OpenChain Webinar #10 - Joint Development Foundation - 2020-08-17
OpenChain Webinar #10 - Joint Development Foundation - 2020-08-17OpenChain Webinar #10 - Joint Development Foundation - 2020-08-17
OpenChain Webinar #10 - Joint Development Foundation - 2020-08-17
 
Open Source at Scania
Open Source at ScaniaOpen Source at Scania
Open Source at Scania
 
Bosch: AN UPDATE ON OUR ACTIVITIES IN AUTOMATING OSS COMPLIANCE: A WORKING SH...
Bosch: AN UPDATE ON OUR ACTIVITIES IN AUTOMATING OSS COMPLIANCE: A WORKING SH...Bosch: AN UPDATE ON OUR ACTIVITIES IN AUTOMATING OSS COMPLIANCE: A WORKING SH...
Bosch: AN UPDATE ON OUR ACTIVITIES IN AUTOMATING OSS COMPLIANCE: A WORKING SH...
 
OpenChain: How to manage OSS licenses for CI/CD development
OpenChain: How to manage OSS licenses for CI/CD developmentOpenChain: How to manage OSS licenses for CI/CD development
OpenChain: How to manage OSS licenses for CI/CD development
 
Using SW360 for OSS Compliance Management Process - A Toshiba Case Study for ...
Using SW360 for OSS Compliance Management Process - A Toshiba Case Study for ...Using SW360 for OSS Compliance Management Process - A Toshiba Case Study for ...
Using SW360 for OSS Compliance Management Process - A Toshiba Case Study for ...
 
Strategies to Reap the Benefits of Software Patents in an Open Source Softwar...
Strategies to Reap the Benefits of Software Patents in an Open Source Softwar...Strategies to Reap the Benefits of Software Patents in an Open Source Softwar...
Strategies to Reap the Benefits of Software Patents in an Open Source Softwar...
 
What in the World is Going on at The Linux Foundation?
What in the World is Going on at The Linux Foundation?What in the World is Going on at The Linux Foundation?
What in the World is Going on at The Linux Foundation?
 
Giving Everyone Access To Open Source Best Practices: The OpenChain Curriculum
Giving Everyone Access To Open Source Best Practices: The OpenChain CurriculumGiving Everyone Access To Open Source Best Practices: The OpenChain Curriculum
Giving Everyone Access To Open Source Best Practices: The OpenChain Curriculum
 
Open source code
Open source codeOpen source code
Open source code
 
Managing the Software Supply Chain: Policies that Promote Innovation While Op...
Managing the Software Supply Chain: Policies that Promote Innovation While Op...Managing the Software Supply Chain: Policies that Promote Innovation While Op...
Managing the Software Supply Chain: Policies that Promote Innovation While Op...
 
Samsung & The Path to Open Source Leadership (OBC)
Samsung & The Path to Open Source Leadership (OBC)Samsung & The Path to Open Source Leadership (OBC)
Samsung & The Path to Open Source Leadership (OBC)
 
Webinar–The 2019 Open Source Year in Review
Webinar–The 2019 Open Source Year in ReviewWebinar–The 2019 Open Source Year in Review
Webinar–The 2019 Open Source Year in Review
 
Why is Open Source Important to Samsung and What Are We Doing About It?
Why is Open Source Important to Samsung and What Are We Doing About It?Why is Open Source Important to Samsung and What Are We Doing About It?
Why is Open Source Important to Samsung and What Are We Doing About It?
 
SFScon 2020 - Davide Ricci - FOSS management and license compliance must come...
SFScon 2020 - Davide Ricci - FOSS management and license compliance must come...SFScon 2020 - Davide Ricci - FOSS management and license compliance must come...
SFScon 2020 - Davide Ricci - FOSS management and license compliance must come...
 
Licensing in Composite Open Source Projects
Licensing in Composite Open Source ProjectsLicensing in Composite Open Source Projects
Licensing in Composite Open Source Projects
 
2011 NASA Open Source Summit - Forge.mil
2011 NASA Open Source Summit - Forge.mil2011 NASA Open Source Summit - Forge.mil
2011 NASA Open Source Summit - Forge.mil
 
Licensing in Composite Projects
Licensing in Composite ProjectsLicensing in Composite Projects
Licensing in Composite Projects
 
Open Source In Enterprises Apache2009 Beijing Jack Cai
Open Source In Enterprises Apache2009 Beijing Jack CaiOpen Source In Enterprises Apache2009 Beijing Jack Cai
Open Source In Enterprises Apache2009 Beijing Jack Cai
 

Similar to OpenChain Webinar #11 - cii-bp-badge-intro

Badge des bonnes pratiques OpenSSF de la CII
Badge des bonnes pratiques OpenSSF de la CIIBadge des bonnes pratiques OpenSSF de la CII
Badge des bonnes pratiques OpenSSF de la CII
Open Source Experience
 
Introduction to the CII Badge Programe, OW2con'16, Paris.
Introduction to the CII Badge Programe, OW2con'16, Paris. Introduction to the CII Badge Programe, OW2con'16, Paris.
Introduction to the CII Badge Programe, OW2con'16, Paris.
OW2
 
Continous Integration: A Case Study
Continous Integration: A Case StudyContinous Integration: A Case Study
Continous Integration: A Case Study
Talentica Software
 
OpenChain Monthly Meeting North America - Europe - 2023-02-07
OpenChain Monthly Meeting North America - Europe - 2023-02-07OpenChain Monthly Meeting North America - Europe - 2023-02-07
OpenChain Monthly Meeting North America - Europe - 2023-02-07
Shane Coughlan
 
OpenChain Monthly Meeting 2023-02-21 (North America and Asia)
OpenChain Monthly Meeting 2023-02-21 (North America and Asia)OpenChain Monthly Meeting 2023-02-21 (North America and Asia)
OpenChain Monthly Meeting 2023-02-21 (North America and Asia)
Shane Coughlan
 
Open Source evaluation: A comprehensive guide on what you are using
Open Source evaluation: A comprehensive guide on what you are usingOpen Source evaluation: A comprehensive guide on what you are using
Open Source evaluation: A comprehensive guide on what you are using
All Things Open
 
Agile And Open Development
Agile And Open DevelopmentAgile And Open Development
Agile And Open Development
Ross Gardler
 
The 6k startup - How to Launch a Startup on a Budget
The 6k startup - How to Launch a Startup on a BudgetThe 6k startup - How to Launch a Startup on a Budget
The 6k startup - How to Launch a Startup on a Budget
Crystal Taggart
 
Software development life cycle
Software development life cycleSoftware development life cycle
Software development life cycle
Afrasiyab Haider
 
OpenChain Germany Work Group Meeting 2022-11-16
OpenChain Germany Work Group Meeting 2022-11-16OpenChain Germany Work Group Meeting 2022-11-16
OpenChain Germany Work Group Meeting 2022-11-16
Shane Coughlan
 
Programming languages and techniques for today’s embedded andIoT world
Programming languages and techniques for today’s embedded andIoT worldProgramming languages and techniques for today’s embedded andIoT world
Programming languages and techniques for today’s embedded andIoT world
Rogue Wave Software
 
OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making...
 OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making... OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making...
OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making...
The Linux Foundation
 
Secure development 2014
Secure development 2014Secure development 2014
Secure development 2014
Ariel Evans
 
Open Source Defense for Edge 2017
Open Source Defense for Edge 2017Open Source Defense for Edge 2017
Open Source Defense for Edge 2017
Adrian Sanabria
 
Software Security Assurance for DevOps
Software Security Assurance for DevOpsSoftware Security Assurance for DevOps
Software Security Assurance for DevOps
Black Duck by Synopsys
 
OaaS:Open as a Strategy
OaaS:Open as a StrategyOaaS:Open as a Strategy
OaaS:Open as a Strategy
OpenCity Community
 
Open source software: The infrastructure impact
Open source software: The infrastructure impactOpen source software: The infrastructure impact
Open source software: The infrastructure impact
Rogue Wave Software
 
DevOps in Cloud OSLC Integration
DevOps in Cloud OSLC IntegrationDevOps in Cloud OSLC Integration
DevOps in Cloud OSLC Integration
Steve Speicher
 
The Coming OSS Sustainability Crisis
The Coming OSS Sustainability CrisisThe Coming OSS Sustainability Crisis
The Coming OSS Sustainability Crisis
Aaron Stannard
 
BsidesMCR_2016-what-can-infosec-learn-from-devops
BsidesMCR_2016-what-can-infosec-learn-from-devopsBsidesMCR_2016-what-can-infosec-learn-from-devops
BsidesMCR_2016-what-can-infosec-learn-from-devops
James '​-- Mckinlay
 

Similar to OpenChain Webinar #11 - cii-bp-badge-intro (20)

Badge des bonnes pratiques OpenSSF de la CII
Badge des bonnes pratiques OpenSSF de la CIIBadge des bonnes pratiques OpenSSF de la CII
Badge des bonnes pratiques OpenSSF de la CII
 
Introduction to the CII Badge Programe, OW2con'16, Paris.
Introduction to the CII Badge Programe, OW2con'16, Paris. Introduction to the CII Badge Programe, OW2con'16, Paris.
Introduction to the CII Badge Programe, OW2con'16, Paris.
 
Continous Integration: A Case Study
Continous Integration: A Case StudyContinous Integration: A Case Study
Continous Integration: A Case Study
 
OpenChain Monthly Meeting North America - Europe - 2023-02-07
OpenChain Monthly Meeting North America - Europe - 2023-02-07OpenChain Monthly Meeting North America - Europe - 2023-02-07
OpenChain Monthly Meeting North America - Europe - 2023-02-07
 
OpenChain Monthly Meeting 2023-02-21 (North America and Asia)
OpenChain Monthly Meeting 2023-02-21 (North America and Asia)OpenChain Monthly Meeting 2023-02-21 (North America and Asia)
OpenChain Monthly Meeting 2023-02-21 (North America and Asia)
 
Open Source evaluation: A comprehensive guide on what you are using
Open Source evaluation: A comprehensive guide on what you are usingOpen Source evaluation: A comprehensive guide on what you are using
Open Source evaluation: A comprehensive guide on what you are using
 
Agile And Open Development
Agile And Open DevelopmentAgile And Open Development
Agile And Open Development
 
The 6k startup - How to Launch a Startup on a Budget
The 6k startup - How to Launch a Startup on a BudgetThe 6k startup - How to Launch a Startup on a Budget
The 6k startup - How to Launch a Startup on a Budget
 
Software development life cycle
Software development life cycleSoftware development life cycle
Software development life cycle
 
OpenChain Germany Work Group Meeting 2022-11-16
OpenChain Germany Work Group Meeting 2022-11-16OpenChain Germany Work Group Meeting 2022-11-16
OpenChain Germany Work Group Meeting 2022-11-16
 
Programming languages and techniques for today’s embedded andIoT world
Programming languages and techniques for today’s embedded andIoT worldProgramming languages and techniques for today’s embedded andIoT world
Programming languages and techniques for today’s embedded andIoT world
 
OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making...
 OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making... OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making...
OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making...
 
Secure development 2014
Secure development 2014Secure development 2014
Secure development 2014
 
Open Source Defense for Edge 2017
Open Source Defense for Edge 2017Open Source Defense for Edge 2017
Open Source Defense for Edge 2017
 
Software Security Assurance for DevOps
Software Security Assurance for DevOpsSoftware Security Assurance for DevOps
Software Security Assurance for DevOps
 
OaaS:Open as a Strategy
OaaS:Open as a StrategyOaaS:Open as a Strategy
OaaS:Open as a Strategy
 
Open source software: The infrastructure impact
Open source software: The infrastructure impactOpen source software: The infrastructure impact
Open source software: The infrastructure impact
 
DevOps in Cloud OSLC Integration
DevOps in Cloud OSLC IntegrationDevOps in Cloud OSLC Integration
DevOps in Cloud OSLC Integration
 
The Coming OSS Sustainability Crisis
The Coming OSS Sustainability CrisisThe Coming OSS Sustainability Crisis
The Coming OSS Sustainability Crisis
 
BsidesMCR_2016-what-can-infosec-learn-from-devops
BsidesMCR_2016-what-can-infosec-learn-from-devopsBsidesMCR_2016-what-can-infosec-learn-from-devops
BsidesMCR_2016-what-can-infosec-learn-from-devops
 

More from Shane Coughlan

openEuler Case Study - The Journey to Supply Chain Security
openEuler Case Study - The Journey to Supply Chain SecurityopenEuler Case Study - The Journey to Supply Chain Security
openEuler Case Study - The Journey to Supply Chain Security
Shane Coughlan
 
OpenChain @ LF Japan Executive Briefing - May 2024
OpenChain @ LF Japan Executive Briefing - May 2024OpenChain @ LF Japan Executive Briefing - May 2024
OpenChain @ LF Japan Executive Briefing - May 2024
Shane Coughlan
 
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCAOpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
Shane Coughlan
 
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
Shane Coughlan
 
OpenChain Education Work Group Monthly Meeting - 2024-04-10 - Full Recording
OpenChain Education Work Group Monthly Meeting - 2024-04-10 - Full RecordingOpenChain Education Work Group Monthly Meeting - 2024-04-10 - Full Recording
OpenChain Education Work Group Monthly Meeting - 2024-04-10 - Full Recording
Shane Coughlan
 
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full RecordingOpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
Shane Coughlan
 
OpenChain Monthly Meeting North America and Asia - 2024-03-19
OpenChain Monthly Meeting North America and Asia - 2024-03-19OpenChain Monthly Meeting North America and Asia - 2024-03-19
OpenChain Monthly Meeting North America and Asia - 2024-03-19
Shane Coughlan
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS Calculator
Shane Coughlan
 
openEuler Community Overview - a presentation showing the current scale
openEuler Community Overview - a presentation showing the current scaleopenEuler Community Overview - a presentation showing the current scale
openEuler Community Overview - a presentation showing the current scale
Shane Coughlan
 
OpenChain AI Study Group - North America and Europe - 2024-02-20
OpenChain AI Study Group - North America and Europe - 2024-02-20OpenChain AI Study Group - North America and Europe - 2024-02-20
OpenChain AI Study Group - North America and Europe - 2024-02-20
Shane Coughlan
 
AI Study Group North America - Europe 2024-02-06
AI Study Group North America - Europe 2024-02-06AI Study Group North America - Europe 2024-02-06
AI Study Group North America - Europe 2024-02-06
Shane Coughlan
 
OpenChain Monthly North America / Europe Call - 2024-02-06
OpenChain Monthly North America / Europe Call - 2024-02-06OpenChain Monthly North America / Europe Call - 2024-02-06
OpenChain Monthly North America / Europe Call - 2024-02-06
Shane Coughlan
 
OpenChain Export Control Work Group 2024-01-09
OpenChain Export Control Work Group 2024-01-09OpenChain Export Control Work Group 2024-01-09
OpenChain Export Control Work Group 2024-01-09
Shane Coughlan
 
OpenChain Legal Work Group - 2024-01-17
OpenChain Legal Work Group -  2024-01-17OpenChain Legal Work Group -  2024-01-17
OpenChain Legal Work Group - 2024-01-17
Shane Coughlan
 
Openchain AI Study Group 2024-01-23.pptx
Openchain AI Study Group 2024-01-23.pptxOpenchain AI Study Group 2024-01-23.pptx
Openchain AI Study Group 2024-01-23.pptx
Shane Coughlan
 
OpenChain Webinar #58 - FOSS License Management through aliens4friends in Ecl...
OpenChain Webinar #58 - FOSS License Management through aliens4friends in Ecl...OpenChain Webinar #58 - FOSS License Management through aliens4friends in Ecl...
OpenChain Webinar #58 - FOSS License Management through aliens4friends in Ecl...
Shane Coughlan
 
Maturity Models - Open Compliance Summit 2023
Maturity Models - Open Compliance Summit 2023Maturity Models - Open Compliance Summit 2023
Maturity Models - Open Compliance Summit 2023
Shane Coughlan
 
OpenChain Annual Report 2023 - Key Metrics Slides
OpenChain Annual Report 2023 - Key Metrics SlidesOpenChain Annual Report 2023 - Key Metrics Slides
OpenChain Annual Report 2023 - Key Metrics Slides
Shane Coughlan
 
OpenChain Webinar 57 - The Open Source Initiative - 2023-11-27
OpenChain Webinar 57 - The Open Source Initiative - 2023-11-27OpenChain Webinar 57 - The Open Source Initiative - 2023-11-27
OpenChain Webinar 57 - The Open Source Initiative - 2023-11-27
Shane Coughlan
 
FOSSLight Community Day 2023-11-30
FOSSLight Community Day 2023-11-30FOSSLight Community Day 2023-11-30
FOSSLight Community Day 2023-11-30
Shane Coughlan
 

More from Shane Coughlan (20)

openEuler Case Study - The Journey to Supply Chain Security
openEuler Case Study - The Journey to Supply Chain SecurityopenEuler Case Study - The Journey to Supply Chain Security
openEuler Case Study - The Journey to Supply Chain Security
 
OpenChain @ LF Japan Executive Briefing - May 2024
OpenChain @ LF Japan Executive Briefing - May 2024OpenChain @ LF Japan Executive Briefing - May 2024
OpenChain @ LF Japan Executive Briefing - May 2024
 
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCAOpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
 
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
 
OpenChain Education Work Group Monthly Meeting - 2024-04-10 - Full Recording
OpenChain Education Work Group Monthly Meeting - 2024-04-10 - Full RecordingOpenChain Education Work Group Monthly Meeting - 2024-04-10 - Full Recording
OpenChain Education Work Group Monthly Meeting - 2024-04-10 - Full Recording
 
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full RecordingOpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
OpenChain AI Study Group - Europe and Asia Recap - 2024-04-11 - Full Recording
 
OpenChain Monthly Meeting North America and Asia - 2024-03-19
OpenChain Monthly Meeting North America and Asia - 2024-03-19OpenChain Monthly Meeting North America and Asia - 2024-03-19
OpenChain Monthly Meeting North America and Asia - 2024-03-19
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS Calculator
 
openEuler Community Overview - a presentation showing the current scale
openEuler Community Overview - a presentation showing the current scaleopenEuler Community Overview - a presentation showing the current scale
openEuler Community Overview - a presentation showing the current scale
 
OpenChain AI Study Group - North America and Europe - 2024-02-20
OpenChain AI Study Group - North America and Europe - 2024-02-20OpenChain AI Study Group - North America and Europe - 2024-02-20
OpenChain AI Study Group - North America and Europe - 2024-02-20
 
AI Study Group North America - Europe 2024-02-06
AI Study Group North America - Europe 2024-02-06AI Study Group North America - Europe 2024-02-06
AI Study Group North America - Europe 2024-02-06
 
OpenChain Monthly North America / Europe Call - 2024-02-06
OpenChain Monthly North America / Europe Call - 2024-02-06OpenChain Monthly North America / Europe Call - 2024-02-06
OpenChain Monthly North America / Europe Call - 2024-02-06
 
OpenChain Export Control Work Group 2024-01-09
OpenChain Export Control Work Group 2024-01-09OpenChain Export Control Work Group 2024-01-09
OpenChain Export Control Work Group 2024-01-09
 
OpenChain Legal Work Group - 2024-01-17
OpenChain Legal Work Group -  2024-01-17OpenChain Legal Work Group -  2024-01-17
OpenChain Legal Work Group - 2024-01-17
 
Openchain AI Study Group 2024-01-23.pptx
Openchain AI Study Group 2024-01-23.pptxOpenchain AI Study Group 2024-01-23.pptx
Openchain AI Study Group 2024-01-23.pptx
 
OpenChain Webinar #58 - FOSS License Management through aliens4friends in Ecl...
OpenChain Webinar #58 - FOSS License Management through aliens4friends in Ecl...OpenChain Webinar #58 - FOSS License Management through aliens4friends in Ecl...
OpenChain Webinar #58 - FOSS License Management through aliens4friends in Ecl...
 
Maturity Models - Open Compliance Summit 2023
Maturity Models - Open Compliance Summit 2023Maturity Models - Open Compliance Summit 2023
Maturity Models - Open Compliance Summit 2023
 
OpenChain Annual Report 2023 - Key Metrics Slides
OpenChain Annual Report 2023 - Key Metrics SlidesOpenChain Annual Report 2023 - Key Metrics Slides
OpenChain Annual Report 2023 - Key Metrics Slides
 
OpenChain Webinar 57 - The Open Source Initiative - 2023-11-27
OpenChain Webinar 57 - The Open Source Initiative - 2023-11-27OpenChain Webinar 57 - The Open Source Initiative - 2023-11-27
OpenChain Webinar 57 - The Open Source Initiative - 2023-11-27
 
FOSSLight Community Day 2023-11-30
FOSSLight Community Day 2023-11-30FOSSLight Community Day 2023-11-30
FOSSLight Community Day 2023-11-30
 

Recently uploaded

GraphSummit Paris - The art of the possible with Graph Technology
GraphSummit Paris - The art of the possible with Graph TechnologyGraphSummit Paris - The art of the possible with Graph Technology
GraphSummit Paris - The art of the possible with Graph Technology
Neo4j
 
Hand Rolled Applicative User Validation Code Kata
Hand Rolled Applicative User ValidationCode KataHand Rolled Applicative User ValidationCode Kata
Hand Rolled Applicative User Validation Code Kata
Philip Schwarz
 
May Marketo Masterclass, London MUG May 22 2024.pdf
May Marketo Masterclass, London MUG May 22 2024.pdfMay Marketo Masterclass, London MUG May 22 2024.pdf
May Marketo Masterclass, London MUG May 22 2024.pdf
Adele Miller
 
Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604
Fermin Galan
 
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
kalichargn70th171
 
Graspan: A Big Data System for Big Code Analysis
Graspan: A Big Data System for Big Code AnalysisGraspan: A Big Data System for Big Code Analysis
Graspan: A Big Data System for Big Code Analysis
Aftab Hussain
 
Microservice Teams - How the cloud changes the way we work
Microservice Teams - How the cloud changes the way we workMicroservice Teams - How the cloud changes the way we work
Microservice Teams - How the cloud changes the way we work
Sven Peters
 
Transform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR SolutionsTransform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR Solutions
TheSMSPoint
 
Energy consumption of Database Management - Florina Jonuzi
Energy consumption of Database Management - Florina JonuziEnergy consumption of Database Management - Florina Jonuzi
Energy consumption of Database Management - Florina Jonuzi
Green Software Development
 
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptxLORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
lorraineandreiamcidl
 
Oracle Database 19c New Features for DBAs and Developers.pptx
Oracle Database 19c New Features for DBAs and Developers.pptxOracle Database 19c New Features for DBAs and Developers.pptx
Oracle Database 19c New Features for DBAs and Developers.pptx
Remote DBA Services
 
OpenMetadata Community Meeting - 5th June 2024
OpenMetadata Community Meeting - 5th June 2024OpenMetadata Community Meeting - 5th June 2024
OpenMetadata Community Meeting - 5th June 2024
OpenMetadata
 
LORRAINE ANDREI_LEQUIGAN_HOW TO USE ZOOM
LORRAINE ANDREI_LEQUIGAN_HOW TO USE ZOOMLORRAINE ANDREI_LEQUIGAN_HOW TO USE ZOOM
LORRAINE ANDREI_LEQUIGAN_HOW TO USE ZOOM
lorraineandreiamcidl
 
Atelier - Innover avec l’IA Générative et les graphes de connaissances
Atelier - Innover avec l’IA Générative et les graphes de connaissancesAtelier - Innover avec l’IA Générative et les graphes de connaissances
Atelier - Innover avec l’IA Générative et les graphes de connaissances
Neo4j
 
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket ManagementUtilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate
 
Artificia Intellicence and XPath Extension Functions
Artificia Intellicence and XPath Extension FunctionsArtificia Intellicence and XPath Extension Functions
Artificia Intellicence and XPath Extension Functions
Octavian Nadolu
 
Automated software refactoring with OpenRewrite and Generative AI.pptx.pdf
Automated software refactoring with OpenRewrite and Generative AI.pptx.pdfAutomated software refactoring with OpenRewrite and Generative AI.pptx.pdf
Automated software refactoring with OpenRewrite and Generative AI.pptx.pdf
timtebeek1
 
DDS-Security 1.2 - What's New? Stronger security for long-running systems
DDS-Security 1.2 - What's New? Stronger security for long-running systemsDDS-Security 1.2 - What's New? Stronger security for long-running systems
DDS-Security 1.2 - What's New? Stronger security for long-running systems
Gerardo Pardo-Castellote
 
A Study of Variable-Role-based Feature Enrichment in Neural Models of Code
A Study of Variable-Role-based Feature Enrichment in Neural Models of CodeA Study of Variable-Role-based Feature Enrichment in Neural Models of Code
A Study of Variable-Role-based Feature Enrichment in Neural Models of Code
Aftab Hussain
 
GreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-JurisicGreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-Jurisic
Green Software Development
 

Recently uploaded (20)

GraphSummit Paris - The art of the possible with Graph Technology
GraphSummit Paris - The art of the possible with Graph TechnologyGraphSummit Paris - The art of the possible with Graph Technology
GraphSummit Paris - The art of the possible with Graph Technology
 
Hand Rolled Applicative User Validation Code Kata
Hand Rolled Applicative User ValidationCode KataHand Rolled Applicative User ValidationCode Kata
Hand Rolled Applicative User Validation Code Kata
 
May Marketo Masterclass, London MUG May 22 2024.pdf
May Marketo Masterclass, London MUG May 22 2024.pdfMay Marketo Masterclass, London MUG May 22 2024.pdf
May Marketo Masterclass, London MUG May 22 2024.pdf
 
Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604
 
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
 
Graspan: A Big Data System for Big Code Analysis
Graspan: A Big Data System for Big Code AnalysisGraspan: A Big Data System for Big Code Analysis
Graspan: A Big Data System for Big Code Analysis
 
Microservice Teams - How the cloud changes the way we work
Microservice Teams - How the cloud changes the way we workMicroservice Teams - How the cloud changes the way we work
Microservice Teams - How the cloud changes the way we work
 
Transform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR SolutionsTransform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR Solutions
 
Energy consumption of Database Management - Florina Jonuzi
Energy consumption of Database Management - Florina JonuziEnergy consumption of Database Management - Florina Jonuzi
Energy consumption of Database Management - Florina Jonuzi
 
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptxLORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
 
Oracle Database 19c New Features for DBAs and Developers.pptx
Oracle Database 19c New Features for DBAs and Developers.pptxOracle Database 19c New Features for DBAs and Developers.pptx
Oracle Database 19c New Features for DBAs and Developers.pptx
 
OpenMetadata Community Meeting - 5th June 2024
OpenMetadata Community Meeting - 5th June 2024OpenMetadata Community Meeting - 5th June 2024
OpenMetadata Community Meeting - 5th June 2024
 
LORRAINE ANDREI_LEQUIGAN_HOW TO USE ZOOM
LORRAINE ANDREI_LEQUIGAN_HOW TO USE ZOOMLORRAINE ANDREI_LEQUIGAN_HOW TO USE ZOOM
LORRAINE ANDREI_LEQUIGAN_HOW TO USE ZOOM
 
Atelier - Innover avec l’IA Générative et les graphes de connaissances
Atelier - Innover avec l’IA Générative et les graphes de connaissancesAtelier - Innover avec l’IA Générative et les graphes de connaissances
Atelier - Innover avec l’IA Générative et les graphes de connaissances
 
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket ManagementUtilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
 
Artificia Intellicence and XPath Extension Functions
Artificia Intellicence and XPath Extension FunctionsArtificia Intellicence and XPath Extension Functions
Artificia Intellicence and XPath Extension Functions
 
Automated software refactoring with OpenRewrite and Generative AI.pptx.pdf
Automated software refactoring with OpenRewrite and Generative AI.pptx.pdfAutomated software refactoring with OpenRewrite and Generative AI.pptx.pdf
Automated software refactoring with OpenRewrite and Generative AI.pptx.pdf
 
DDS-Security 1.2 - What's New? Stronger security for long-running systems
DDS-Security 1.2 - What's New? Stronger security for long-running systemsDDS-Security 1.2 - What's New? Stronger security for long-running systems
DDS-Security 1.2 - What's New? Stronger security for long-running systems
 
A Study of Variable-Role-based Feature Enrichment in Neural Models of Code
A Study of Variable-Role-based Feature Enrichment in Neural Models of CodeA Study of Variable-Role-based Feature Enrichment in Neural Models of Code
A Study of Variable-Role-based Feature Enrichment in Neural Models of Code
 
GreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-JurisicGreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-Jurisic
 

OpenChain Webinar #11 - cii-bp-badge-intro

  • 1. An Introduction to the Core Infrastructure Initiative (CII) Best Practices Badge David A. Wheeler, dwheeler AT linuxfoundation DOT org Director of Open Source Supply Chain Security Linux Foundation 2020-08-30 0
  • 2. Antitrust Policy Notice  Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.  Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation. 1 See: https://www.linuxfoundation.org/antitrust-policy/
  • 3. Heartbleed  In 2014, Heartbleed vulnerability found in OpenSSL  Highlighted OSS* projects don’t always follow widely accepted practices, which results in avoidable problems 2 *OSS=Open source software. OSS is licensed to its users in a way that allows them to run the program for any purpose, study and modify the program, and freely redistribute copies of either the original or modified program (without royalties to original author, etc.)
  • 4. OSS project practices matter!  It is not true that “all OSS is insecure” … or that “all OSS is secure”  It is not true that “all OSS is poor quality” … or that “all OSS has excellent quality”  OSS tends to be more secure & higher quality if the project follows good practices  Good people necessary, but insufficient  Both creators & users of OSS want good results  What are those good practices?  How can we encourage projects to follow them?  How can anyone know if they’re being followed? 3
  • 5. CII* Best Practices Badge  Identified best practices for OSS projects  For production of OSS**  Based on practices of well-run OSS projects  Increase likelihood of better quality & security  Criteria designed for any OSS project  Web application: OSS projects self-certify  If OSS project meets criteria, it gets a badge  No cost  Self-certification mitigated by automation, public display of answers (for criticism), spot-checks, and can be overridden if false 4 ** for receiving OSS, esp. license compliance, see OpenChain* CII = Core Infrastructure Initiative
  • 6. Who created & runs the Badging Project?  Linux Foundation (LF)  “dedicated to building sustainable ecosystems around open source projects to accelerate technology development and industry adoption”  nonprofit mutual benefit corporation, 501(c)(6)  Linux kernel, JS Foundation, Cloud Native Computing Foundation (CNCF), R Consortium, LF Energy, …  Core Infrastructure Initiative (CII) organized by LF  “to fund and support critical elements of the global information infrastructure”  Badging project is an OSS project created by CII  Yes, we earn our own badge  5
  • 7. BadgeApp: Home page 6 To get your OSS project a badge, go to https://bestpractices.coreinfrastructure.org/
  • 8. Some OSS projects with a best practices badge 7 GNU Make
  • 9. CII badges are increasingly getting adopted! 8Source: https://bestpractices.coreinfrastructure.org/project_stats as of 2020-07-02 All projects Projects with non- trivial progress Over 3,200 projects participating! 450 passing! General availability May 2016
  • 10. Badge levels  Three badge levels (passing, silver, gold)  For higher levels, must meet previous level  Passing:  Captures what well-run projects typically already do  Not “they should do X, but no one does that”  66 criteria in 6 groups:  Basics, Change Control, Reporting, Quality, Security, Analysis  Silver: Harder but possible for 1-person projects  Gold requires multiple developers  bus factor > 1*, 2-person review 9 Source: https://github.com/coreinfrastructure/best-practices-badge/ blob/master/doc/criteria.md
  • 11. Badge criteria developed to be reasonable!  Relevant  Attainable by typical OSS projects (esp. passing)  Clear  Include security-related criteria (but not only those)  Consensus of developers & users  Criteria & web app developed as OSS project  Built on existing work, e.g., Karl Fogel’s Producing Open Source Software  Not hypocritical  Our web app must get its own badge! 10 Worked with several projects, such as the Linux kernel & curl, to test criteria validity
  • 12. Non-requirements  Does NOT require any specific technology, product, or service  Does NOT require or forbid any particular programming language  Sometimes includes tips  Exception: Expect projects to have a web page with TLS  NEVER requires proprietary software or service  You may use or depend on it  Does NOT cost anything  Does NOT “take over your project”  Does NOT require doing everything immediately  Some projects have immediately earned a badge  Most projects try for a badge, find some things missing, & gradually work to fix those issues 11
  • 13. Sample passing badge criteria (yes, they’re reasonable)  “The project website MUST succinctly describe what the software does (what problem does it solve?).” [description_good]  “The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project).” [test]  “At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language.” [static_analysis]  “The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.” [sites_https]  “The project MUST publish the process for reporting vulnerabilities on the project site.” [vulnerability_report_process] 12*FLOSS=Free/Libre/Open source software Available in English, Chinese, French, German, Japanese, & Russian Each criterion has a unique id; each id shown here in brackets
  • 14. Badge scoring system  To obtain a badge, all:  MUST and MUST NOT criteria (42/66*) must be met  SHOULD (10/66*) met, OR unmet with justification  Users can see those justifications & decide if that’s enough  SUGGESTED (14/66*) considered (met or unmet)  People don’t like admitting they didn’t do something  In some cases, URL required in justification (to point to evidence; 8/66* require this) 13 * For the passing badge
  • 15. Miscellaneous info  Badging web application has automation  Automatically examines projects on creation/edits  Fills in some info & rejects obviously incorrect  Some larger organizations require badging  Open Network Automation Platform (ONAP)  Cloud Native Computing Foundation (CNCF) graduation requirement  Supports easy display of badge info  GitHub-style badge for README  REST API & CORS for easy display of info 14 For details, see (ONAP) https://wiki.onap.org/display/DW/CII+Badging+Program (CNCF graduation) https://www.cncf.io/projects/graduation-criteria/ (Dashboard example) https://landscape.cncf.io/selected=kubernetes
  • 16. Sample impacts of CII badge process  OWASP ZAP (web app scanner)  Simon Bennetts: “[it] helped us improve ZAP quality… [it] helped us focus on [areas] that needed most improvement.”  Change: Significantly improved automated testing  CommonMark (Markdown in PHP) changes:  TLS for the website (& links from repository to it)  Publishing the process for reporting vulnerabilities  JSON for Modern C++  “I really appreciate some formalized quality assurance which even hobby projects can follow.”  Change: Added explicit mention of how to privately report errors  Change: Added a static analysis check to continuous integration script 15Source: https://github.com/coreinfrastructure/best-practices-badge/wiki/Impacts
  • 17. Conclusions  Involved in an OSS project? Get a badge!  Start here: https://bestpractices.coreinfrastructure.org  Don’t need to do “everything at once” – just start!  Questions? Email or create an issue  Prefer using OSS from projects using best practices  They are trying to “do the right thing”  You want to use OSS from projects like that!  CII best practices badge helps identify those projects  Criteria need additions/refinements?  Let us know, we’re also an OSS project  More info:  https://github.com/coreinfrastructure/best-practices-badge  https://github.com/coreinfrastructure/best-practices- badge/wiki/Videos 16 Get or check on badges at: https://bestpractices.coreinfrastructure.org
  • 19. Many projects working towards silver & gold 18 Progress to silver Progress to gold Source: https://bestpractices.coreinfrastructure.org/project_stats ?type=uncommon as of 2020-07-02 112 projects are halfway or better, including 16 projects with silver 27 projects are halfway or better, including 6 projects with gold
  • 20. Some communities encouraging badges  Cloud Native Computing Foundation (CNCF)*  Maturity levels: Sandbox → incubating → graduated  For graduated level must “have achieved and maintained a CII Best Practices Badge.”  Containerd graduated, has passing badge  R community discussing recommending badges  2018 survey:  90% believe badge will provide value to the R community’s package developers or package users  77% saying it has benefit for both developers and users  74% would be willing to try it  Multiple R packages tried it out & began working towards badges as part of discussion  DBI passing  Close to passing include ggplot2, covr, dodgr, netReg 19 Sources: CNCF Graduation Criteria v1.2 https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc “Should R Consortium Recommend CII Best Practices Badge for R Packages: Latest Survey Results” https://www.r- consortium.org/blog/2018/07/26/should-r-consortium-recommend-cii-best-practices-badge-for-r-packages-latest-survey-results
  • 21. Remote access enabled  Can easily embed current badge image  <img src="https://bestpractices.coreinfrastructure. org/projects/PROJECT_NUMBER/badge">  Easily shows current state on GitHub, etc.  REST API enables easy JSON data access  Including project database download for analysis  See https://github.com/coreinfrastructure/best- practices-badge/blob/master/doc/api.md  Cross Origin Resource Sharing (CORS)  Enables data access from client-side JavaScript  E.g., for fancy client-side dashboards 20
  • 22. Example: CNCF landscape  CNCF landscape <https://landscape.cncf.io/> easily accesses badge data 21
  • 23. Sample impacts of CII badge process (1 of 2)  OWASP ZAP (web app scanner)  Simon Bennetts: “[it] helped us improve ZAP quality… [it] helped us focus on [areas] that needed most improvement.”  Change: Significantly improved automated testing  CommonMark (Markdown in PHP) changes:  TLS for the website (& links from repository to it)  Publishing the process for reporting vulnerabilities  OPNFV (open network functions virtualization)  Change: Replaced no-longer-secure crypto algorithms  JSON for Modern C++  “I really appreciate some formalized quality assurance which even hobby projects can follow.”  Change: Added explicit mention how to privately report errors  Change: Added a static analysis check to continuous integration script 22Source: https://github.com/coreinfrastructure/best-practices-badge/wiki/Impacts
  • 24. Sample impacts of CII badge process (2 of 2)  BRL-CAD  Probably would have taken an hour uninterrupted, getting to 100% passing was relatively easy  Website certificate didn’t match our domain, fixed  POCO C++ Libraries  “... thank you for setting up the best practices site. It was really helpful for me in assessing the status…”  Updated the CONTRIBUTING.md file to include a statement on reporting security issues  Updated the instructions for preparing a release in the Wiki to include running clang-analyzer  Enabled HTTPS for the project website  GNU Make  HTTPS. Convinced Savannah to support HTTPS for repositories (it supported HTTPS for project home pages) 23Source: https://github.com/coreinfrastructure/best-practices-badge/wiki/Impacts
  • 25. Sample clarifications  vulnerabilities_fixed_60_days (PR #1188)  “There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days.”  Added: “… this badge criterion, like other criteria, applies to the individual project. Some projects are part of larger umbrella… An individual project often cannot control the rest, but an individual project can work to release a vulnerability patch in a timely way.”  hardened_site (PR #1187)  “The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers… [GitHub is known to meet this]”  Added: “Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective.” 24
  • 26. Most common challenges for getting a badge  All projects 90%+ but not passing (2019-03-07)  265 projects. MUST with Unmet or “?” => Top 10 challenges: 25 # Criterion %miss Old rank# 1 vulnerability_report_process 21% 1 2 tests_are_added 17% 3 3 vulnerability_report_private 15% 4 4 know_secure_design 13% 9 5 vulnerabilities_fixed_60_days 13% 24 6 test_policy 13% 5 7 know_common_errors 13% 7 8 static_analysis 11% 8 9 static_analysis_fixed 11% 21 10 sites_https 9% 2 This data is as of 2019-03-07, old rank from 2017-09-06 Analysis Vulnerability reporting Tests HTTPS Know secure development Mostly same challenges as 2017-09-06. HTTPS becoming less of a problem, dropped from #2 to #10. Unclear why fixing things has become bigger problem..! Fixing
  • 27. Tests  Criteria  #1 The project MUST have evidence that such tests are being added in the most recent major changes to the project. [tests_are_added]  #4 The project MUST have a general policy (formal or not) that as major new functionality is added, tests of that functionality SHOULD be added to an automated test suite. [test_policy]  Automated testing is important  Quality, supports rapid change, supports updating dependencies when vulnerability found  No coverage level required – just get started 26
  • 28. Vulnerability reporting  Criteria  #2 “The project MUST publish the process for reporting vulnerabilities on the project site.” [vulnerability_report_process]  #8 “If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private.” [vulnerability_report_private]  Just tell people how to report!  In principle easy to do – but often omitted  Projects need to decide how 27
  • 29. HTTPS  #3 “The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.” [sites_https]  Details:  You can get free certificates from Let's Encrypt.  Projects MAY implement this criterion using (for example) GitHub pages, GitLab pages, or SourceForge project pages.  If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) as a proxy to support HTTPS.  We’ve been encouraging hosting systems to support HTTPS 28
  • 30. Analysis  #5 “At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language.” [static_analysis]  A static code analysis tool examines the software code (as source code, intermediate code, or executable) without executing it with specific inputs.  #6 “All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed.” [dynamic_analysis_fixed]  Early versions didn’t allow “N/A”; this has been fixed. 29
  • 31. Know secure development  Criteria  #8 “The project MUST have at least one primary developer who knows how to design secure software.” [know_secure_design]  #9 “At least one of the primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them.” [know_common_errors]  Specific list of requirements given – doesn’t require “know everything”  Perhaps need short “intro” course material? 30
  • 32. Documentation  #10 “The project MUST include reference documentation that describes its external interface (both input and output).” [documentation_interface]  Some OSS projects have good documentation – but some do not 31
  • 33. Application security: Using an assurance case  We want applications to be generally secure  However, security:  Can’t be directly measured (“how many kilograms”)  Is an emergent property (totality of components)  Is often a negative property (“never does X”)  How can you know “we’ve done enough”?  “Did long list of things” doesn’t provide confidence  How do you know those were the right things?  Must be able to justify & refine later  Must avoid breaking the bank  Useful approach: an “assurance case”  Starts with the overall goal  Repeatedly break the goal into smaller parts  Not complicated – keeps track of what needs to be done  Pattern we’ve used may be useful to you too! 32
  • 34. Assurance case: Top level (figure 1) 33 Assets & threat actors identified & addressed System is adequately secure against moderate threats Confidentiality Integrity Availability Security implemented in all software development processes Security requirements identified and met by functionality Security implemented by software life cycle processes See next figure Access control Identifi- cation Authenti- cation Authori- zation Fill in the more specific requirements, then the arguments of why they are met (design, implementation, verification,…) – but avoid repetition
  • 35. Assurance case: Next level (partial figure 2) 34 … Not a waterfall- These are processes, not phases
  • 36. Life cycle technical processes (figure 2) 35 Verification: many tools Design: Esp. attack model + Saltzer & Schr- oeder principle s
  • 37. Security in implementation (figure 3) 36 All OWASP top 10 (2013 & 2017) countered Entire most- relevant security guide applied Hardening applied Hardened outugoing HTTP headers, including restrictive CSP Incoming rate limits Force HTTPS, including via HSTS CSRF token harden- ing Outgoing email rate limit 1. Injection (incl. SQL injection) 2. Auth & session 3. XSS 4. Insecure object references 5. Security misconfiguration 6. Sensitive data exposure 7. Missing access control 8. CSRF 9. Known vulnerabilities 10. Unvali- dated redirect/fwd See securely reuse (supply chain) See security guide applied Most implementation vulnerabilities are due to common types of implementation errors or common misconfigurations, so countering them greatly reduces security risks Reduce/eliminate impact if defect exists All of the most common important implementation vulnerability types (weaknesses) countered All of the most common known security-relevant misconfiguration errors countered 11. XXE (2017 A4) 12. Insecure deserialization (2017 A8) 13. Insufficient logging and ,onitoring (2017 A10) Encrypted email addresses Cookie limits Securely reuse Review before use Get authentic version Use package manager Security in implementation OWASP Top 10 Web hardening, esp. CSP Reuse/ Supply chain
  • 38. BadgeApp dependencies and security  Tiny amount of new code in our system…  Because almost all code is reused  Direct dependencies = 75 gems  Direct AND indirect dependencies = 197 gems  Plus OS, language runtime, RDBMS, etc.  Today a key security concern for most projects is vulnerabilities through their dependencies  Minimize dependencies, ask them to minimize their run-time dependencies, sanity check of direct dependencies  Package manager: Track what we have, trivially update packages  Dependency tools*: detect & report packages with known vulnerabilities (GitHub + bundle audit)  Thorough automated tests: enable quick update, test, & ship to production (we have 100% coverage)  Other measures, esp. hardening (such as CSP), reduce risk in meantime 37 * Origin analysis / software composition analysis tools
  • 39. Got on Hacker News (HN)!  Badge-related post got on Hacker News front page on 2018-10-06  “Certainly not knocking on the badge or the practices…I just found it amusing that PHP often gets a bad rap, but then shows up at the top of the listed projects for objectively good development practices.” - reindeerer  “I just found and read through the criteria list. It's mind-bogglingly exhaustive, but in a very good way, and an excellent catalyst for maintainable, secure software. I'd regard it as universally applicable to any and all code.” – exikyut  “Lots of self-proclaimed ‘experts’ love to say ‘do X and Y and Z and you will be successful because these are best practices’, but it's all a bunch of snake oil… ‘Best practices are best not practiced.’” – userbinator, dissenting, but then downvoted & replied to…  “Best practices are a bit like good genes. [They’re] by no means a guarantee of success, fame, glory and riches, but damn if they don't make things easier.” - reindeerer  “I see absolutely nothing dogmatic or cargo cult about the recommendations they make. They are completely sensible, and a decent guideline for improving the technical support infrastructure of a project.” - throwaway2048 38Source: https://news.ycombinator.com/item?id=18157494
  • 40. Natural languages supported  English (en)  Chinese (Simplified) / 简体中文 (zh-CN)  French / Français (fr)  German / Deutsch (de)  Japanese / 日本語 (ja)  Russian / Русский (ru) 39 Even if you can’t understand the detailed justifications, you can see the criteria & claimed answers Our sincere thanks to all the hard-working translators!!
  • 41. Open source software  OSS: software licensed to users with these freedoms:  to run the program for any purpose,  to study and modify the program, and  to freely redistribute copies of either the original or modified program (without royalties to original author, etc.)  Original term: “Free software” (confused with no-price)  Other synonyms: libre sw, free-libre sw, FOSS, FLOSS  Antonyms: proprietary software, closed software  Widely used; OSS #1 or #2 in many markets  “… plays a more critical role in the DoD than has generally been recognized.” [MITRE 2003]  OSS almost always commercial by law & regulation  Software licensed to general public & has non-government use  commercial software (in US law, per 41 USC 403) 40
  • 42. Statistics about the criteria themselves 41 Level Total active MUST SHOULD SUGG- ESTED Allow N/A Met justifi- cation or URL required Includes details New at this level Passing 66 42 10 14 27 9 48 66 Silver 55 44 10 1 39 54 38 48 Gold 23 21 2 0 9 21 15 14 Source: https://bestpractices.coreinfrastructure.org/criteria as of 2017-09-10 There are not a lot of gold criteria, but they’re challenging.
  • 43. Passing criteria categories and examples (1) 1. Basics  The software MUST be released as FLOSS*. [floss_license]  It is SUGGESTED that any required license(s) be approved by the Open Source Initiative (OSI). [floss_license_osi] 2. Change Control  The project MUST have a version-controlled source repository that is publicly readable and has a URL. [repo_public]  Details: The URL MAY be the same as the project URL. The project MAY use private (non-public) branches in specific cases while the change is not publicly released (e.g., for fixing a vulnerability before it is revealed to the public). 3. Reporting  The project MUST publish the process for reporting vulnerabilities on the project site. [vulnerability_report_process] 42 *FLOSS=Free/Libre/Open Source Software
  • 44. Passing criteria categories and examples (2) 4. Quality  If the software requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code. [build]  The project MUST have at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). [test]  The project MUST have a general policy (formal or not) that as major new functionality is added, tests of that functionality SHOULD be added to an automated test suite. [test_policy]  The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. [warnings] 43
  • 45. Passing criteria categories and examples (3) 5. Security  At least one of the primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them. [know_common_errors]  The project's cryptographic software MUST use only cryptographic protocols and algorithms that are publicly published and reviewed by experts. [crypto_published]  The project MUST use a delivery mechanism that counters MITM attacks. Using https or ssh+scp is acceptable. [delivery_mitm]  There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days. [vulnerabilities_fixed_60_days] 44
  • 46. Passing criteria categories and examples (4) 6. Analysis  At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language… [static_analysis]  It is SUGGESTED that the {static code analysis} tool include rules or approaches to look for common vulnerabilities in the analyzed language or environment. [static_analysis_common_vulnerabilities]  It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release. [dynamic_analysis] 45
  • 47. Silver: Sample criteria (1 of 2)  The project MUST clearly define and document its project governance model (the way it makes decisions, including key roles). [governance]  The project MUST be able to continue with minimal interruption if any one person is incapacitated or killed… [you] MAY do this by providing keys in a lockbox and a will providing any needed legal rights (e.g., for DNS names). [access_continuity]  The project MUST have FLOSS automated test suite(s) that provide at least 80% statement coverage if there is at least one FLOSS tool that can measure this criterion in the selected language. [test_statement_coverage80]  The project MUST automatically enforce its selected coding style(s) if there is at least one FLOSS tool that can do so in the selected language(s). [coding_standards_enforced]  The project MUST implement secure design principles (from "know_secure_design"), where applicable… [implement_secure_design] 46
  • 48. Silver: Sample criteria (2 of 2)  The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (a whitelist), and reject invalid inputs, if there are any restrictions on the data at all. [input_validation]  The project MUST cryptographically sign releases of the project results intended for widespread use, and there MUST be a documented process explaining [how to] obtain the public signing keys and verify the signature(s)… [signed_releases]  The project MUST provide an assurance case that justifies why its security requirements are met. [It MUST…] [assurance_case]  The project MUST use at least one static analysis tool … to look for common vulnerabilities… , if there is at least one FLOSS tool that can… [static_analysis_common_vulnerabilities]  Projects MUST monitor or periodically check their external dependencies (including convenience copies) to detect known vulnerabilities, and fix exploitable vulnerabilities or verify them as unexploitable. [dependency_monitoring] 47
  • 49. Gold: Sample criteria  The project MUST require two-factor authentication (2FA) for developers for changing a central repository or accessing sensitive data (such as private vulnerability reports)… [require_2FA]  The project MUST have at least 50% of all proposed modifications reviewed before release by a person other than the author… [two_person_review]  The project MUST have a "bus factor" of 2 or more. [bus_factor]  The project MUST have a reproducible build… [build_reproducible]  The project MUST apply at least one dynamic analysis tool to any proposed major production release of the software before its release. [dynamic_analysis]  The project MUST have performed a security review within the last 5 years. This review MUST consider the security requirements and security boundary. [security_review]  Hardening mechanisms MUST be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities. [hardening] 48
  • 50. Key URLs  CII best practices badge (get a badge):  https://bestpractices.coreinfrastructure.org/  CII best practices badge project:  https://github.com/coreinfrastructure/best-practices- badge 49 My thanks to the many who reviewed or helped develop the badging criteria and/or the software to implement it. This includes: Mark Atwood, Tod Beardsley, Doug Birdwell, Alton(ius) Blom, Hanno Böck, enos-dandrea, Jason Dossett, David Drysdale, Karl Fogel, Alex Jordan (strugee), Sam Khakimov, Greg Kroah-Hartman, Dan Kohn, Charles Neill (cneill), Mark Rader, Emily Ratliff, Tom Ritter, Nicko van Someren, Daniel Stenberg (curl), Marcus Streets, Trevor Vaughan, Dale Visser, Florian Weimer
  • 51. Involved in OSS?  If you lead an OSS project, what you do matters!  People depend on the software you create  The practices you apply affect the result  Secure or quality software is not an accident  Please try to get a badge, & show when you have it  If you’re considering using an OSS project  Check on the project – should you use it? 50
  • 52. Release of presentation  This presentation is released under Creative Commons Attribution 3.0 or later (CC-BY-3.0+)  Credits  Older versions were developed by the Institute for Defense Analyses (IDA); thank you! 51

Editor's Notes

  1. Hi, my name’s David A. Wheeler. This presentation is an introduction to the Core Infrastructure Initiative (CII) Best Practices Badge. I hope to convince you that if you are part of an open source software project, you should try to get a best practices badge to help you identify and follow best practices. I also hope to convince you that if you use open source software, you should look for and prefer software that is following best practices, and that the badge can help you identify such projects. To get there, this presentation will explain the basics of the CII best practices badge. We’ll first start with a little history, which I think will help why the badge exists.
  2. In 2014, the Heartbleed vulnerability was found in the OpenSSL cryptographic library. OpenSSL is widely used, so this vulnerability had a big impact. However, the bigger issue was that when people investigated the OpenSSL project itself, many didn’t like what they saw. At the time the OpenSSL project didn’t have a lot of support and failed to apply some widely accepted practices. Defects, including vulnerabilities, can happen to any project, but avoidable problems are something else. == Heartbleed logo is free to use, rights waived via CC0, per http://heartbleed.com/
  3. In short, the practices used by an OSS project affect its users. It is NOT true that all OSS is insecure, or that all OSS is secure. Similarly, it is NOT true that all OSS is of poor quality, or that it all has excellent quality. Instead, OSS tends to be more secure and higher quality if the project follows good practices. Practices aren’t enough, of course, because OSS projects need good people to develop the software. But good people aren’t enough. If the project doesn’t test the software that the project develops, or doesn’t use version control software, or doesn’t follow other widely accepted good practices, then many avoidable problems typically result. Both creators and users of open source software want good results, so it’d be helpful to encourage identifying those practices and encouraging their use. But what are those good practices? How can we encourage projects to follow them? And how can anyone know if those good practices being followed by some particular project?
  4. This leads us to the CII best practices badge. We identified a set of best practices for producing OSS, based on the practices of well-run OSS projects. Each practice increases the likelihood of producing better quality or security. We then turned those practices into a simple set of criteria that can be applied to any OSS project. Some criteria also apply to proprietary software, but many don’t, because many criteria focus on enabling worldwide review and participation. We also developed a web application that allows OSS projects to self-certify that they meet the criteria. If an OSS project meets the criteria, the project gets a corresponding badge. All of this is at no cost to the OSS projects. We chose self-certification because there are literally millions of OSS projects, and self-certification can scale to such sizes. Self-certification systems can have problems, so we countered those problems in a variety of ways. Perhaps the most important is that we automate the process; in a number of cases we automatically determine if a project meets a criterion. We also require that the answers be public, so that the public can judge the accuracy of the answers. We do spot-checks, and the answers can even be overridden if a project falsifies their answers. As a result, we believe we’ve developed an approach that scales yet provides good confidence in those answers.
  5. The badging project was created by the Linux Foundation’s Core Infrastructure Initiative, abbreviated as CII. The Linux Foundation is a nonprofit mutual benefit corporation which already supports a wide variety of OSS projects that you probably use every day, such as the Linux kernel, JS foundation, cloud native computing foundation, and R consortium. The badging project is itself an OSS project, and you’ll be glad to know that we earn our own badge.
  6. If you can’t remember anything else from this presentation, please remember that if you participate in an OSS project, please go to https://bestpractices.coreinfrastructure.org and start the process of getting a badge. What you see here is a quick screenshot of our home page, you just click on the green button to get started. You can also click on the Projects link to see some of the other projects that have or are working on getting a badge.
  7. Lots of OSS projects have earned a best practices badge. You’re probably using many of them now. Badge earners include the Linux kernel, Kubernetes, Node.js, and curl. The OpenSSL project has made a number of changes, and they’ve earned a badge too. === Most of the logos shown here have a trademark owned by their respective project. They’re shown here to help quickly identify them (and congratulate them!).
  8. As you can see, since May 2016 when the CII Badging project became generally available we’ve had continuous growth in the number of participating projects and the number of projects that have earned a passing badge.
  9. There are three badge levels: passing, silver, and gold. “Passing” captures what well-run projects typically already do. Silver is harder but is still possible for 1-person projects. Gold is even more difficult and includes criteria that require multiple developers.
  10. It’s important to understand that these criteria were specifically developed to be reasonable. This slide briefly lists some of the questions we asked before adding any criterion. I’m not going to go into these points in detail, I just want to emphasize that we strived to create reasonable criteria. We also worked with a number of projects to develop and review the criteria, to make sure they would work in a variety of circumstances.
  11. Perhaps most important is what we do not do. We do not require any particular technology, product, or service. For example, we do not require or forbid any particular programming language. We do include tips for some common circumstances, but those are simply suggestions to help people in those common circumstances. One exception is that we do expect projects to have a web page and use TLS to secure web pages, because this provides a widely-used standard and secure way to get basic information. We never require proprietary software or a proprietary service, though projects may choose to use them. Getting a badge doesn’t cost anything. We do not “take over your project” – we simply present the criteria, and your project can decide how to meet them or even if the project should meet them. Most importantly, we do not require that everything be done immediately. Some well-run projects have immediately earned a badge, but most projects find that they are missing a few things. That’s not a problem – just fill in the website form with your current state, and update it later as you resolve those issues.
  12. Here are a few sample criteria. I’m just going to quickly read them to you, and hopefully you’ll agree that these are reasonable things for an OSS project to do. Note that the criteria use the term FLOSS instead of OSS, to try to include everyone who develops such software regardless of their motivations. Every criterion has a unique identifier; identifiers are shown here in square brackets. Please let me just read them to you. “The project website MUST succinctly describe what the software does (what problem does it solve?).” [description_good] “The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project).” [test] “At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language.” [static_analysis] “The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.” [sites_https] “The project MUST publish the process for reporting vulnerabilities on the project site.” [vulnerability_report_process] Again, I hope you’ll agree that these are reasonable things for an OSS project to do. The text of these criteria are available in a variety of natural languages.
  13. Of course, we had to implement a badge scoring system. To obtain a badge, all the MUST and MUST NOT criteria must be met. In addition, criteria that says SHOULD have to be met or they can be unmet if there is a justification for it. Users who review the badge answers can review those justifications and determine if they are enough. Note that MUST, MUST NOT, and SHOULD all have their usual IETF meanings. Some criteria are merely SUGGESTED. SUGGESTED criteria are criteria where there are many reasons that they might not apply to a particular circumstance or might be excessively difficult. We have some SUGGESTED criteria because we believe that people don’t like admitting they didn’t do something if it’s obvious they should. Some criteria specifically require URLs to point to evidence. Higher-level badges require more evidence.
  14. Here is some miscellaneous information. As I mentioned earlier, the badging web application automates some steps. When you create a project entry we try to automatically fill in information, and when a project entry is edited we reject information that is obviously incorrect. That makes the badging process simpler and more accurate. Some larger organizations already require badges in some cases, including the open network automation platform and the cloud native computing foundation. This shows that at least some organizations think that the badge is worth getting. The badge application makes it easy to display badge information, for example, projects on GitHub can easily modify their README to display their current badge status. We have a REST API and support Cross-Origin Resource Sharing, also known as CORS. The REST API and CORS to make it easy to get and display information for specialized needs, for example, to support specialized dashboards.
  15. Many projects have said that getting a CII badge has been very helpful. The OWASP ZAP project knew that they should have automated testing, but the desire to get a badge helped them turn their aspiration into a reality. The CommonMark project implemented HTTPS for their website and published how to report vulnerabilities to their project. The library JSON for modern C++ added information on how to privately report errors and added a static analysis check to their continuous integration script. These changes weren’t difficult, and the JSON for Modern C++ project said that they appreciated that these changes could be even done by hobby projects.
  16. Are you involved in an OSS project? If you are, I strongly encourage you to try to get a badge for your project. Simply start at the badging website, https://bestpractices.coreinfrastructure.org. Don’t wait until you’re ready, simply get started and you can see what if anything is left to do. If you have questions, send us an email or create an issue, using a link at the bottom of every webpage. If you’re looking at using some OSS, you should prefer to use OSS from projects that are applying best practices. Such projects are trying to do the right thing, and you want to use OSS from projects like that. It can be time-consuming to evaluate projects this way, so the CII best practices badge can help you identify such projects. We’ve done our best to create good criteria, but nothing is perfect. If you think the criteria need additions or refinements, let us know. The best practices badge project is itself an OSS project, so we’d love to hear from you. If you want additional information, the URLs shown here should help. The bottom line is: Get or check on best practices badges for OSS on https://bestpractices.coreinfrastructure.org. Thank you for your time.
  17. https://landscape.cncf.io/project=graduated&selected=containerd
  18. To determine what the “top 10” challenges are, I examined the projects that have at least 90% passing but not 100%, and sorted the MUST criteria that were “Unmet” or “?”. I didn’t include “SHOULD” or “SUGGESTED”, since those can be justified away with text. I skipped the “future” criterion crypto_certificate_verification_status, since it is not required. The script “compute-criteria-stats” in the repository computed these. Warning sign: https://openclipart.org/detail/104263/warning-sign Beaker: https://openclipart.org/detail/272207/beaker-icon Green tick: https://openclipart.org/detail/17014/greentick Brain: https://openclipart.org/detail/140701/brain All openclipart is released to the public domain (CC0), see: https://openclipart.org/share Books: https://openclipart.org/detail/192515/stack-of-three-books Unlock icon from http://www.iconsdb.com/red-icons/unlock-icon.html - This icon is provided by icons8 as Creative Commons Attribution-NoDerivs 3.0.
  19. Physical LOC: Code 3,181; Test 2,831 https://codeclimate.com/blog/deciphering-ruby-code-metrics/