May I please join the working group? When are its next meetings?

Assemble a technical paper that captures relevant known-good practices for secure development, oss tooling, and build/deploy, and related functions. We'll begin with a google doc(1) and once done, transfer to md file in OSSF repo.

(1) - Existing Guidelines for Developing and Distributing Secure Software - https://docs.google.com/document/d/11bRB-Q_j9sj19EEC32-ijMiEHERPRwZRVWE9HwNr2pc/edit#heading=h.gxoel3nswm76

Hi all, A small question,

As showed in the README,

The Developer Best Practices group wants to help identfy and curate an accessible inventory of best practices
Prioritized according to ROI for open source developers
Categorized per technology, language, framework
Community-curated

What's the meaning of curate and Community-curated? I checked the dictionary where there's only one noun meaning but none sense for this. Can anybody explain for me? Thanks a lot.

The CII has been doing work for years in developing & refining a set of best practices for developing secure open source software. Over 3,300 projects are participating.

I'd be happy to talk about it at length. Some URLs:

• CII Best Practices Badge Program (website for getting a badge)
• Criteria for "passing" level (with rationale)
• Criteria for silver & gold
• GitHub repo for CII Best Practices

"The Best and Worst GCC Compiler Flags For Embedded" (22 Oct 2019 by Chris Coleman) lists many potential C/C++ flags to add to our list:

He claims "The Best One-Off Warning Options (options not covered by -Wall or -Wextra)" are:

-Wshadow
-Wdouble-promotion
-Wformat=2 & -Wformat-truncation
-Wundef
-fno-common
-fstack-usage & -Wstack-usage=
-Wconversion

We already include -Wformat=2, but I don't think we include the others.

He also recommends -Weverything (Clang only), but as noted, that's rather controversial. We should probably mention it though.

Team - During our 14March WG call(1) a proposal was made to create a new SIG under the BEST Practices working group that seeks to refine the OpenSSF's Mobilization plan stream 4(2) . To that end, we ask all eligible members(3) to express their opinion, ask questions, provide feedback, and ultimately vote for or against (or abstain) to adopt this work under our umbrella.

The core group has met several times(4) already and has a diverse group of folks participating so far and would benefit from our engagement and participation. Their proposal can be found here(5). Eligible WG members, please review these materials and express your opinion in this issue (as "+1", "-1", "Yes", "No", "Agree", "Disagree", "Abstain" or however you feel comfortable) no later than 28March2023 so we can discuss any outstanding questions and determine next steps. Thank you for your time and participation.

(1) - https://docs.google.com/document/d/1x-fMIt6ZIV6SM-M29xEVKeB505GbDzSIVXg-8uF_FQU/edit#heading=h.ol1uqtnxytpe
(2) - https://8112310.fs1.hubspotusercontent-na1.net/hubfs/8112310/OpenSSF/White%20House%20OSS%20Mobilization%20Plan.pdf?hsCtaTracking=3b79d59d-e8d3-4c69-a67b-6b87b325313c%7C7a1a8b01-65ae-4bac-b97c-071dac09a2d8
(3) - https://github.com/ossf/wg-best-practices-os-developers/blob/main/README.md#governance
(4) - https://docs.google.com/document/d/1Ehpp1UmAIqMs0ZdKr15sd5MS48OeaGKB9H40htVehs4/edit?usp=sharing
(5) - https://openssf.slack.com/files/U03451TRVHT/F04U8CVU85P/memory_safety_sig_proposal.pdf?origin_team=T019QHUBYQ3&origin_channel=C01AHCRP8BT

Description

Include CodeQL labs and queries into SKF

Discussion minutes

• Specific python CodeQL examples for the level 1 ASVS Design patterns
  — http://localhost:4200/projects/manage
  — http://localhost:4200/projects/view/1
  — Per security requirement an CodeQL Python example how to very that requirement
  — If not codeQL query existing then link the generic codeql item
  — The MD files /skf-flask/skf/markdown/code_examlples/web/testing/
  — markdown filename convention example 11-code_example--codeQL_2_1_1.md (the 2_1_1 is the security requirement identifier)

• Check with the LGTM if we can reuse their web query editor and completion
  — blabla1337/skf-labs#97
  — Maybe we can use the standalone version?

Add machine learning to:
https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Existing%20Guidelines%20for%20Developing%20and%20Distributing%20Secure%20Software.md

Here's a source of some information:
https://dwheeler.com/secure-class/presentations/Secure-Software-10-Misc.ppt

More information welcome!

I am not able to find a process of how to join the WG. Could you please point me in that direction?

We would like to create specialized content for various developer types. There is an initial effort underway targeting web developers for specialized content, where W3C would be a potential collaborator. This issue aims to collect all developer types and identify potential collaborators who could help with similar content.

Please add your input/thoughts/comments in this doc

Once we have the list in a decent spot, we will prioritize and short-list developer types where we have existing expertise and have collaborators identified. Then we can close this issue and move onto working on the content.

The -Wl,-z,noexecheap command-line option is not supported by gold or lld 12.0.0.

It's an interesting question if we should be recommending options that aren't very portable. At the very least, we should be more specific about where this is supported. Binutils isn't very helpful since 50% of the linkers don't work.

Hi there. My name is CRob and I work for Red Hat Product Security. In addition to the vulnerability management processes for the company, we are also responsible for governance and SDLC-like activities across our OSS-based portfolio. I'm interested in joining this group to help further the OSSF initiative and larger community efforts around improving open source software. I'm heavily involved in the PSIRT community and spend a lot of time educating industry and customers about securing open source software. I'm looking forward to collaborating with everyone soon!

-CRob

To assist us in understanding the user stories we want to address as part of this working group I started drawing out a high-level workflow of the process of finding and fixing vulnerabilities in open source and third-party components that I'd love to get everyone's feedback on.

As the diagram is viewed, let me explain the elements/convergences.
There are at least 3 separate working groups working to address part of the problem "How do vulnerabilities get fixed within OSS software" (probably also several others I'm unaware of):
OpenSSF Vulnerability Disclosure Group - OSS maintainer/ecosystem-focused, trying to standardize and provide guidance on vulnerability remediation in OSS components. This is the "head-end" of the process from my perspective.
OpenSSF Developer Best Practice Group - OSS maintainer-focused, trying to provide guidance and resources around secure software development, which elements include reacting to vulnerabilities as they are identified (and
techniques/tools to capture them before they become escapes). This is the longer-term. lessons-learned, teaching aspect that will help share whatever standards processes the community agrees upon.
FIRST PSIRT Third Party Component Management Group - Focused on Vendors/Suppliers that consume (or are involved on some level) with third party hardware and software components.

The diagram shows a high-level flow from when a vuln gets report to where an fix is released to where a downstream supplier picks that fix up and provides it to their consumers. Our OpenSSF groups are only primarily concerned with the first few steps of this where a Reporter/Finder and Maintainer/Project interact and fix the issue (or not). There are several external factors like industry standards, concepts like secure supply chain, slide, or software bill of materials that are related to this process, but not directly part of the work we're concerned with at this stage (or in these particular groups). The Supplier piece is also less interesting to maintainers, so I'm not looking for feedback on that angle in this forum at this point (if you have feels about it, let me know and I can get that to the appropriate group).

I welcome thoughts, suggestions, collaboration on the attached diagram and the concepts detailed within. Hopefully this can help us focus in on the gaps/pain points of this process to address developer/maintainer concerns. Thanks!

OpenSSF Vuln & Dev Diagrams - Workflow.pdf

The linter is giving

 /github/workspace/README.md:23 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]
/github/workspace/README.md:24 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 3]
/github/workspace/README.md:109 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Areas that need contributions"]
/github/workspace/README.md:110 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- Any topics related to helpin..."]
/github/workspace/README.md:110 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- Any topics related to helpin..."]
/github/workspace/README.md:111 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Above] [Context: "### Where to file issues"]
/github/workspace/README.md:111 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Where to file issues"]
/github/workspace/README.md:112 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- Issues can be reviewed and f..."]
/github/workspace/README.md:132 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Project Collaborators"]
/github/workspace/README.md:133 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- [Glenn ten Cate, OWASP/SKF](..."]
/github/workspace/README.md:146:2 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1]
/github/workspace/README.md:146 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "-"]
/github/workspace/README.md:147 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Above] [Context: "### Project Contributors"]
/github/workspace/README.md:147 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Project Contributors"]
/github/workspace/README.md:148 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- Laurent Simon, Google/Scorec..."]
/github/workspace/README.md:161 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]

All: I've been developing some educational materials to help teach software developers the basics on how to develop secure software. Presumably best practices should be included, and I think having software developers know how to develop secure software is itself a best practice. This not intended to be a graduate course, but it is intended to cover the basics for many different kinds of software.

Here's my current draft outline. I'd love to hear feedback. Thanks!

• Course Introduction
  • Standard Introductions
  • Motivation
    • Motivation: Why is it important to secure software?
    • Motivation: Why take this course?
• Security basics
  • What do we need?
    • What does “security” mean?
    • Security requirements
  • How can we get there?
    • Risk Management
      • Need for risk management
      • Risk management process
      • Identifying risks
      • Security is a process, not a product
      • Checklists are not security
    • Development Processes / Defense-in-Breadth
    • Protect, detect, respond
    • Vulnerabilities
      • CVEs
      • Top kinds of vulnerabilities
      • Value of knowing top kinds of vulnerabilities
• Design
  • Secure Design Basics
    • What are security design principles?
    • What secure design principles are widely recommended?
    • Least privilege
      • Ways to implement least privilege
      • Examples of least privilege
    • Complete mediation (“non-bypassability”)
    • The Rest of the S&S Design Principles
    • Other Design Principles
      • Beware of Race Conditions
      • Harden the system
      • Keep Secrets Secret
      • Trust only trustworthy channels
      • Separate Data from Control
• Reusing external software
  • Supply Chain
    • Basics of reusing software
    • Selecting
    • Updating Reused Software
      • Updating who reused software components
      • Updating How You Use Reused Software (Avoid/Replace Obsolete Interfaces)
      • Reusing software: Wrap-up
• Part II: Implementation
• Basics of Implementation
  • Implementation Overview
• Input Validation
  • Input Validation Basics
    • Input Validation Basics
  • Input Validation: Numbers and Text
    • Input Validation: A Few Simple Data Types
      • Numbers
      • Well-known special text formats
    • Sidequest: Text, Unicode, and locales
      • Code points and encoding
      • Locales
      • Unicode equivalence
      • Visual spoofing
      • Moving on
    • Validating text
    • Introduction to Regular Expressions
    • Using Regular Expressions for Text Input Validation
      • Match, don’t search
      • Know Your Regex Implementation
      • Branch priority
      • Test input validators
    • Countering ReDOS attacks on Regular Expressions
  • Input Validation: Beyond Numbers and Text
    • Insecure deserialization
    • Input Data Structures (XML, HTML, CSV, JSON, & File Uploads)
      • XML
      • HTML
      • CSV
      • JSON
      • File uploads
    • Minimizing attack surface, authentication, and authorization
    • Advanced Issue: Environment Variables (setuid/setgid programs and PATH)
    • Special Inputs: Secure Defaults and Secure Startup
• Processing data securely
  • Processing data securely: General issues
    • Prefer trusted data - treat untrusted data as radioactive
    • Avoid default & hardcoded credentials
      • Avoid default credentials
      • Avoid hardcoded credentials, store them safely instead
    • Avoid incorrect conversion or cast
  • Processing Data Securely: Undefined Behavior / Memory Safety
    • Countering out-of-bounds reads and writes (buffer overflow)
      • Memory safety
      • Out-of-bounds reads/writes and buffer overflow
      • Solutions for out-of-bounds reads and writes
    • Double-free and Use-after-free
    • Avoid undefined behavior
• Calling Other Programs
  • Introduction to Securely Calling Programs
    • Introduction to Securely Calling Programs
  • Calling Other Programs: Injection and Filenames
    • SQL Injection
      • SQL Injection Vulnerability
      • SQL Injection Solutions
    • OS Command (Shell) injection
    • Filenames (including path traversal)
      • Path traversal
      • Windows pathnames
      • Unix/Linux pathnames
  • Calling Other Programs: Other Issues
    • Call APIs for Programs and Check What’s Returned
    • Handling errors
      • Return codes
      • Exceptions
      • Other approaches
      • Error handling wrap-up
    • Logging
    • Debug and assertion code
      • Debug code
      • Assertions
    • Countering Denial-of-Service (DoS) attacks
• Sending output
  • Introduction to Sending Output
  • Countering Cross-Site Scripting (XSS)
    • The XSS Problem
    • The XSS Solution: Escape Output
    • When You Need to Allow Unescaped Untrusted Data
    • URLs
    • XSS Alternatives
  • Content Security Policy (CSP)
  • Other HTTP Hardening Headers
  • Cookies & Login Sessions
    • Cookie attributes
    • Cookies in context
    • Cookies and login sessions
  • CSRF / XSRF
  • Open redirects and forwards
  • HTML target and JavaScript window.open()
  • Using inadequately checked URLs / Server-side request forgery (SSRF)
  • Format Strings & Templates
  • Minimize Feedback / Information Exposure
• PART III: Verification and Advanced Topics
• Verification
  • Basics of Verification
    • Verification Overview
      • Verification approaches
      • True and False Reports
      • Applying tools
  • Static analysis
    • Static analysis overview
      • Human review
      • Generic bug-finding tools: Quality tools, compiler warnings, and type-checking tools
      • Security code scanners / static application security testing (SAST) tools
      • Other static analysis tools
    • Software Component Analysis (SCA) / Dependency Analysis
      • Need for SCA
      • Preparing for the inevitable: Vulnerabilities in your dependencies
  • Dynamic analysis
    • Dynamic analysis overview
      • Limitations to dynamic analysis
      • Traditional testing
      • Traditional testing for security
      • Test coverage
    • Fuzz testing
    • Web application scanners
  • Other verification topics
    • Combining verification approaches
• Design - Advanced Topics
  • Threat Modeling / Attack Modeling
    • Introduction to Threat Modeling
    • STRIDE
• Implementation - Advanced Topics
  • Cryptography
    • Introduction to Cryptography
    • Symmetric/Shared Key Encryption Algorithms
      • Choosing a symmetric key algorithm
      • Choosing a mode
    • Cryptographic hashes (digital fingerprints)
    • Public-key (asymmetric) cryptography
    • Cryptographic pseudo-random number generator (PRNG)
    • Storing passwords
    • Transport Layer Security (TLS)
      • Certificate validation
      • Ciphersuites
    • Other topics in cryptography
      • Getting cryptographic advice
      • Constant time algorithms
      • Minimizing the time keys/decrypted data exists
      • Quantum computing
      • Humility is important in cryptography
• Other topics
  • Miscellaneous
    • Assurance cases
    • Distributing, Fielding/deploying, operations, and disposal
    • Formal methods
      • Formal methods levels
      • How can math be applied?
      • Formal methods tools
      • Formal methods and the future
  • Top vulnerability lists
    • OWASP Top 10
    • CWE top 25
      • Top 25
      • On the cusp
  • Concluding notes
    • Conclusions
• References/Further Reading

ALL: As noted in issue #4, I've been working on a course about developing secure software. I suspect many of us agree that knowing how to develop secure software is a best practice :-).

If you're interested in seeing or reviewing the draft contents of this course, please send me an email with a subject line like "Request early access to secure software development course". My email address:

dwheeler AT linuxfoundation DOT org.

I would love to have your feedback/suggestions/etc.

The draft course material is a Google docs document. My plan is to provide "Suggestion" access to people, so that you can directly suggest specific changes (my preference!). If you have broader suggestions that aren't easy to capture that way, create comments.

Our educational folks have asked me to divide up the course. I've divided it into 3 parts:

• Secure Software Development - Part I, Fundamentals [Covers basics, requirements, design] - est. 2-4 hours
• Secure Software Development - Part II, Implementation - est. 4-6 hours
• Secure Software Development - Part III, Verification and Advanced Topics [Covers verification, threat models, cryptography, & other advanced topics] - est. 3-5 hours

Don't take the estimates too seriously, I'm sure things will change anyway.

I stated this in one of the comments in issue #4, but I thought it might be considered "buried"... so I'm creating this separate issue so that anyone who cares will know.

Thank you!

I am seeing the Readme like this:

Hello,

My name is Dave Russo and I work for Red Hat on the Product Security team (CRob's partner in crime). We are responsible for vulnerability response, governance and secure development and SDLC-like activities, and I would be interested in joining this workgroup to help contribute to the efforts for open source secure development practices.

Thanks!
Dave Russo

As we near publication of our two "quick guides" we need to craft a blog to be published via an OSSF blog for the following gdocs:

One page guide for developing secure software - https://docs.google.com/document/d/16jUqTEFG-wscZUGR-NGa_3a81GF3YILtH9XgOSkLCTM/edit#

Concise Guide for evaluating OSS - https://docs.google.com/document/d/19015o63pA-sZPBN5-R7I7Cg8ICPxo6fXH8vOI1RgBYM/edit#

Hi. The OSSF TAC is seeking to get an issue(1) closed out. We want to ensure all working groups have a complete charter.md file and as I reviewed this group's file I noticed a few items that should be addressed please:

• date approved - the WG should officially review and approve its charter and note that date
• link TSC to contributors under Section 2 (most likely the WG's contributors list - https://github.com/ossf/wg-best-practices-os-developers/graphs/contributors)

Thank you for attending to this matter!

(1) - ossf/tac#9

The current version of the concise guide lists:

“Monitor known vulnerabilities in your software’s direct & indirect dependencies. E.g., use GitHub dependabot & GitLab dependency scanning. Quickly update vulnerable dependencies.”

I'd like to suggest that this needs to be more vendor neutral, either by removing references to specific dependency tracking tools entirely or by listing more tools…?

There are many programs written in C or C++. Compiler option flags can help reduce some of their risks, but to my knowledge there's no common place for that.

We had started creating one here:

"Recommended compiler option flags for C/C++ programs"
https://docs.google.com/document/d/1SslnJuqbFUyTFnhzkhC_Q3PPGZ1zrG89COrS6LV6pz4/edit

It's still in early draft form. Should we work on this further?

I believe that one of the practices should be to do most if not all the code in modern, memory safe languages like Rust.

As we frame our work and start to address user stories to improve OSS Development Best Practice, I am proposing several general and specific user personas in the development and vulnerability coordination processes. These items are informed by work the OpenSSF Vuln Disclosure WG is working on, work from the FIRST TPC WG and FIRST PSIRT Service Framework WG, and informed by upcoming changes in ISO/IEC29147 & 30111.

This is related to:
ossf/wg-vulnerability-disclosures#91

General Personas:
Maintainer - Creates and/or maintains software component
Finder/Researcher - Finds and researches vulnerabilities
Supplier - Supplies, supports, or repackages components
Consumer - Consumes component directly or indirectly
"Other" - [not fleshed out yet, but basically a category that includes Coordinators (like CERT/CC, JP-CERT, etc, or HackerOne et. al), Vulnerability Scanner Vendors, and Regulator] Supplies or Ingests information about component for consumers

Depending on the particular use case of community these personas are used with/in, we've also identified several more precise personas that may add value to a given user story or analysis. These all do not directly apply to the work or concerns of OSS maintainers, but are part of the real world ecosystem:

Specific Personas:
Component Maintainer - person(s) that develop, maintain, or support a software component. This is representing the OpenSSF Vuln Coordination persona "Alice"
Community Member - person(s) that support and/or work with the Maintainer (could be supporting function [quality engineering, peer reviewer, etc.])
Supplier PSIRT - Supplier product security team that monitors/assists with vulnerable components
Supplier Developer - supplier developer that makes further changes to component for subsequent distribution. Could also be Component Maintainer or Community Member (strongly encouraged). This is representing the OpenSSF Vuln Coordination persona "Cherry"
Consumer PSIRT - Product security team for organization/entity that is consuming upstream components (and that may or may not also supply them to entities further downstream)
Consumer CSIRT - Corporate security team responsible for protecting organizational assets that would use upstream components. This is representing the OpenSSF Vuln Coordination persona "Finn"
Consumer Developer - Developer that integrates or uses upstream component for organization
Consumer Business Owner - The business owner of the service/capability using the upstream component This is representing the OpenSSF Vuln Coordination persona "Jacob"
Consumer's Downstream - End-consumers of offerings the Consumer produces or support
Coordinator - Group that assists in the coordination/facilitator of vulnerability remediation
Vulnerability Scanner Vendor - Group that consumes vulnerability information to inform subscribers of threats/vulns
Regulator - Government or Industry body that sets standards for constituents. Interested in vulnerability remediation of its constituents

There are several others, but most are not germane directly to the goals of this particular working group. I look forward to the group's thoughts and collaboration.
OpenSSF Vuln & Dev Diagrams - Personas.pdf

in docs/SCM-BestPractices/README.md, there is language that does not apply to all audiences

to elaborate on the contextual differences to which guidance will be different, in consideration are:

• OSS projects with a small number of maintainers with no GH org
• OSS projects with a small number of maintainers with a GH org
• OSS projects run by a larger community, perhaps with governance
• OSS projects run by companies, which can have varying levels of community engagement and contribution, policy, etc.
• ... and so on

examples of guidelines that would not apply in some cases:

• Organization Management Should Be Consolidated Under a Central Account.
• Organization Membership Should Be Limited to Employees.

the two options I see are:

• make the language/guidelines generic enough to apply broadly enough for different situations. this could manifest as caveats, removing certain guidelines, or providing multiple options that are suitable
• have different, tailored guidelines that are contextual where prudent

It would be better for the docs to be in Markdown than in Powerpoint docs, more accessible.

I was looking at the demo site (https://demo.securityknowledgeframework.org/) today and I noticed that the cert. expired on the 6th.

 openssl s_client -showcerts -connect demo.securityknowledgeframework.org:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.securityknowledgeframework.org
verify error:num=10:certificate has expired
notAfter=Sep  6 10:18:48 2021 GMT
verify return:1
depth=0 CN = *.securityknowledgeframework.org
notAfter=Sep  6 10:18:48 2021 GMT
verify return:1

https://www.securityknowledgeframework.org/ is showing an expired certificate.

$ echo | openssl s_client -connect securityknowledgeframework.org:443 | openssl x509 -noout
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = securityknowledgeframework.org
verify error:num=10:certificate has expired
notAfter=Dec 29 21:00:24 2020 GMT
verify return:1
DONE

@xcorail

We will be using the description listed in the .github/settings.yml for each project to create a summary list for the OpenSSF website getting started page and an upcoming press release. Please edit the description field to include a short (1-2 sentence) description. Due Date - Thursday 10/8/2020

See example here:
https://github.com/ossf/gb-planning-committee/blob/master/.github/settings.yml

GCC 13.1 is now out. We should review its analyzer options, e.g.: https://gcc.gnu.org/gcc-13/changes.html
I think it'd make sense to maximally enable the analyzers in most cases... but I'm happy to hear alternative views.

Team - please review our project charter:

https://github.com/ossf/wg-best-practices-os-developers/blob/main/CHARTER.md

and provide any feedback.

Then please express your vote to adopt it or not by EoD 7Dec2022.

If we want to have some concrete results to show by the OpenSSF
press release at the end of October, we need to take some steps now.

Detailed proposal here:

#19

I tried using this with libc++ and it blew up pretty bad. I'm using _LIBCPP_DEBUG now instead.

https://libcxx.llvm.org/DesignDocs/DebugMode.html
https://releases.llvm.org/12.0.0/projects/libcxx/docs/DesignDocs/DebugMode.html

The following page mentions _LIBCPP_ASSERT but doesn't say you should define it:
https://releases.llvm.org/8.0.0/projects/libcxx/docs/DesignDocs/DebugMode.html

Taking a look at https://github.com/ossf/tac#technical-initiatives the Technical Initiatives table, reading the name of this project, I first thought it was 'working group best practices operating systems developers', and only realized what it really was about once I opened the repo and started reading the readme. Maybe it's too late to rename this project/repo, just thought I'd let you know the name can be misleading.

You might want to reconsider the -z nodump flag.

I discovered that it is not supported by lld 12.0.0

I was investigating to see if it was supported by a later version and found this:

https://reviews.llvm.org/D52096

Which suggests that it is not particularly useful.

I'm inclined to suggest that you remove this recommendation from your guide or clarify further where and how it makes sense to use this flag.

The image on the home page needs some fixing:

• Remove "edX' because the course is on multiple platforms
• Rename "CII" to "OpenSSF" on the badge.

@SecurityCRob - do you have the original image to edit?

Propose to add section providing guidance on the content of a published package to improve security for consumers.

Basic guidance recommended: package the smallest set of content that allows delivery of intended functionality.

Rationale:

1. All of the content bundled in a package is accessible and provides opportunity for abuse without directly contributing to the intended functionality of the package.
2. It is also difficult and impractical to ascertain what content of a package is required from the point of view of any consumer. The further removed a consumer is from [indirect] dependencies the harder it becomes to understand what is actually relevant/required.
3. Tools that may scan for issues will be most thorough by scanning all of the content. Keeping the content small will reduce cost, improve turn-around time, and may allow for more thorough analysis.

Examples of content that should be excluded include helper files used to generate the package and files used for verification including test data and code.

FYI, CII Best Practices badge has a new mechanism to make it easier to integrate in to dashboards:
coreinfrastructure/best-practices-badge#1460

You can easily see the passing criteria here:
https://bestpractices.coreinfrastructure.org/criteria/0

Currently, we don't enforce any consistent markdown style.

I think it would make sense to add Markdownlint via GitHub's Super-Linter in a GitHub Action.

All current documents can be auto-reformatted to comply once an agreed Markdownlint configuration is established.

I propose that this best practices WG coordinate with the "security threats" WG on any future criteria changes in the CII Best Practices badge, e.g., by voting on such changes by members of either WG. I further propose that this be voted on in the next WG.

There seems to be general agreement among OpenSSF participants that it'd be fine to move the CII Best Practices badge into an OpenSSF working group (WG), but there are two plausible working groups for it: The security threats WG (with its focus on metrics) and the best practices WG. No matter what, it's important that the groups work together.

Identifying security threats WG issue #9 proposes moving the CII Best Practices badge project officially into the "identifying security threats" WG (due to its metrics focus), but that any criteria changes be coordinated between both WGs.

It would also be possible to move the CII Best Practices badge to the "Best Practices" WG as well. I think it's important to identify one "official" home, but even more important to set up a way to ensure both WGs are involved (and not surprised!) in any changes.

Proposal

It's considered best-practice, when updating a dependency that fixes a vulnerability in a piece of software that vendors dependencies, ie. that can't be directly updated by the end-user, that the project issue their own disclosure of that vulnerability, and reach out to the CNA for the original vulnerability to add their advisory to the list of links.

This is the CVE way of communicating "we were impacted by this CVE, but we also fixed it".

Notes

Vendoring doesn't always require that deps are committed to source code. Case in point: Gradle/Gradle

The existing OpenSSF fundamentals course has some material on build and distribution security. It'd be useful to expand that using information from SLSA, SSC, and other materials.

When are the meeting times? I can see regular meetings tend to occur at the start of every month but I cannot find any details on when they are. Would be good to add this to the README of this repo.

Thanks!

As discussed in the working group meeting, I would like to help in general with the SCM best practices, but more specifically help add Azure Repos to the list of SCMs. The idea is to discuss the topic next meeting.

The current version of the C/C++ hardening guide is incredibly helpful in supporting GCC and CLang.
Opening this issue to track the work that our team with @michaelcfanning and @GabrielDosReis intends to contribute towards adding support for the Microsoft C/C++ compiler and linker options to the hardening guide.

As discussed on today's (3/1/23) phone call, I'm putting together a paper with the default compiler options used by each independent Linux distro.

https://docs.google.com/document/d/1QGyDVgu0bGdKkdSIIJMHW35R044vGLa6-9tVs86A4_8/edit?usp=sharing

Proposal:

Creating a single document that compiles GitHub security best practices in a clear and consistent format.
The document will help security teams, DevOps engineers, and developers implement security best practices in the GitHub platform.
Additionally, such a document could assist in the development of software that automatically validates these configurations.

Rationale:

1. The GitHub platform contains many security-related settings that, if misconfigured, could impose serious security risks.
2. GitHub adds new features consistently, making it hard for security teams to keep updated with the latest security best practices and constantly understand the risk their configuration exposes.

Some Examples:

1. Code review is not enforced
2. Webhooks are configured insecurely
3. Stored secret is accessible to multiple users
4. MFA is not used by default
5. ...

Other examples can be found here: link

Who we are

We are Legit Security, a cybersecurity company that aims to secure SDLC and prevent software supply chain attacks. We have in-depth knowledge in the field of SDLC misconfigurations, and we'd love to help create this document.