The purpose of the Open Source Security Foundation (the “OpenSSF”) is to inspire and enable the community to secure the open source software (OSS) we all depend on. The OpenSSF Security Baseline combines process, configurations, and tooling to help open source projects achieve this mission. The OpenSSF Security Baseline establishes the minimum practical security standards for OpenSSF software projects throughout various lifecycle stages, ensuring a strong Minimum Viable Secure Product (MVSP) across Linux Foundation projects and internal work.
Existing OpenSSF materials, including guides and other technologies will be used to frame the baseline, define objectives, provide implementation recommendations, and suggest verification methods. Through community engagement and collaboration, the baseline will first be adopted by a few software-based pilot projects before being fully adopted by all OpenSSF projects.
The Security Baseline provides a foundational framework for systematic adoption across the Linux Foundation. Collaboration with peer foundations is essential for baseline customization and adoption, aiming to enhance the security of the open source software ecosystem.
As technology and the threat landscape evolve, the baseline will continuously adapt. The primary goal of this initiative is to maintain a balance between security, reliability, performance, and cost-effectiveness.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
The initiative was one of the outcomes of the October 2023 Linux Foundation Member Summit. Making open source software more secure is one of the top priorities across the Linux Foundation. OpenSSF is leading the charge.
The security of open source software is a matter of global interest and concern. In the United States, open source software is used across all critical infrastructure sectors defined by CISA (Cybersecurity and Infrastructure Security Agency), for example, health care, defense, financial services, utilities, telecommunications, etc. Open source security directly impacts national security, economics and social stability. Enhancing open source security is imperative. NIST has published a Secure Software Development Framework (SSDF) as a result of Executive Order (EO) 14028 on "Improving the Nation's Cybersecurity".
In the European Union, Cyber Resiliency Act (CRA) has declared a new role - Open Source Steward(Article 3(18a). The legislation is to ensure that consumers of products with digital features are protected, and manufacturers of these products are held accountable for product security. Open source security is the foundation for manufacturers to be compliant with the legislation.
The success of the security baseline SHOULD be quantified and qualified in a few dimensions:
- Adoption and Advancement of Security Technologies
- Objective: The Security Baseline promotes improved open source security outcomes.
- Approach: Utilize technical outcomes from the OSS community to implement, and verify the security baseline.
- Collaborations: Partner with other foundations to enhance OSS security through education, specifications, frameworks, and tooling.
- Automation and Tooling: Identify opportunities for automation and tooling to ease the burden on maintainers and contributors, facilitating secure by design and secure by default principles.
- Increased Security Baseline Adoption Rate
- Objective: Ensure the Security Baseline is widely adopted.
- Metrics:
- Three OpenSSF software-based pilot projects meet the baseline requirements for each project's life cycle by 9/15/2024.
- All OpenSSF software-based projects meet the baseline requirements for each project's life cycle by the end of 2024, an aspirational goal.
- At least two other Linux Foundation (LF) foundations adopt the baseline by the end of 2024, an aspirational goal.
- Reduction in Security Findings
- Objective: Measure the effectiveness of the baseline in improving a project’s security posture.
- Metrics:
- Use OpenSSF Scorecard statistics to track the reduction of Critical, High, and Medium risk findings through the project lifecycle. Benchmark is established at the adoption time.
- Monitor the number of exceptions at both project and foundation levels, expecting a decline as projects mature and become more secure.
- Improved OSS Maintainer and Consumer Experience
- Objective: Enhance the experience for both OSS maintainers and consumers.
- Approach: Shift security left in the OSS supply chain to reduce downstream risks.
- Shared Responsibility: Encourage private sector consumers to support OSS security by funding or contributing developer hours.
The Security Baseline SHALL apply to technical initiatives under the OpenSSF GitHub enterprise accounts.
Ecosystem support for tooling and configuration capabilities: They vary depending on the programming languages and the roadmaps for new features or feature enhancements.
Shortage of contributors for tooling development: Security in open source can only be achieved at scale with the right tool. Lack of easily adopted tools prevents us from achieving a higher level of security baseline.
Maintainers' time constrained by disproportionate open-source consumer demands: The security baseline aims to enable more secure software development at speed. Nevertheless, the primary constraint remains the limited time available to maintainers, coupled with the demand for open-source software maintenance, including the enhancement of software security.
To navigate these constraints, the following operating principles are adopted:
- Strong Bias Towards Automation and Automatability
- Objective: Enhance security by default and position security as an enabler rather than an inhibitor.
- Approach: Prioritize automation and automatability to manage dependencies and vulnerabilities more effectively.[Know, Prevent, Fix], [software supply chain transparency logical model]
- Minimal, Achievable, and Practical Security Baseline Requirements
- Objective: Design a security baseline that balances software reliability, performance, cost, and security.
- Approach:
- Ensure the Security Baseline is minimal and achievable with current technology.
- Allow for incremental adoption throughout a software project’s lifecycle by shifting security left in the SDLC process.
- Reuse existing OpenSSF guides and technologies with minimal new requirements.
- Documented Governance Process
- Objective:
- Establish a consistent set of objective security measures for all participating foundations and projects.
- Ensure the Security Baseline is an integral part of the TAC Technical Initiative life cycle process, and maintenance of the baseline follows the TAC decisioning process.
- Approach:
- Provide clear, implementable, and definitive guidelines for maintainers and contributors.
- Incorporate the baseline into OpenSSF Technical Advisory Council (TAC) technical initiative life cycle process.
- Rely on every adopting project to submit issues to log the friction points and provide feedback to refine the Security Baseline, facilitating easier adoption.
- Revision to the baseline will be a community effort following the TAC Issue/PR process.
- Objective:
As a software project progresses through the OpenSSF technical initiative life cycle, it is beneficial to incrementally integrate more security measures.
- Sandbox stage: Baseline awareness, and initial requirements
- Incubation stage: Sandbox requirements plus additional baselines to sustain the secure project development and protect early adopters.
- Graduated stage: Incubation baseline plus additional baselines to prepare for its general availability and sustainability.
This phased approach intends to support maintainers, contributors, and the community in innovating quickly with security built into the design or enabled by default.
When the project starts, it's critical to have a security foundation to reduce a class of vulnerabilities and secure your digital assets with strong credential protections.
| Security Baseline | Objective | How to Implement | How to Verify |
|---|---|---|---|
| A memory-safe language is adopted for new projects or new components. | Reduce memory safety vulnerabilities at scale. | Choose one of the memory-safe languages For preexisting projects in C or C++, follow the Compiler Options Hardening Guide |
Check the file extension and compare with the code. |
| Two-factor authentication (2FA) is enabled for repository interactive access. | Reduce the risks of credential compromise and attacks on the digital assets. | 2FA is enabled by default at the enterprise level for all the organizations. Refer to SCM Best Practices for more information. See instructions for device setup. |
2FA verification, drift detection and correction provides details for verifying 2FA is enabled, monitoring and restoring 2FA if it’s disabled. |
As the project codebase grows and more features are added, increasing complexity, it becomes crucial to leverage security tools to identify vulnerabilities in the codebase or dependent software early on. Addressing critical issues early prevents costly fixes in the future. At this stage, projects MUST onboard to OpenSSF Scorecard by following the installation instructions of Scorecard GitHub Action. The Action runs on any repository change and raises alerts. Repository administrators, organization owners, and people with write or maintain access to a repository can view the alerts in the repository’s Security tab. Ensure Scorecard is enabled for the project by following Scorecard Verify Runs instruction.
| Security Baseline | Objective | How to Implement | How to Verify |
|---|---|---|---|
| There are no hard-coded active secrets in the project source repository. | Prevent unauthorized access to repository assets. | GitHub secret scanning and push protection is enabled in the enterprise account. Repo admin can disable the setting for a sandbox project. The setting is monitored and enforced by the staff members. | Secret Scanning and Push Protection Verification, Drift Detection and Correction provides information for verifying secret scanning and push protection config is as expected, monitoring and restoring the config if it drifts. |
| Credentials are provisioned with minimal permissions. | Minimize security risks by only granting necessary access to reduce potential attack surfaces. | Apply Principle of Least Privilege to manage programmatic and interactive access. Follow this guide to grant GITHUB_TOKEN the least required permissions in your workflows. Establish role-based access control by assigning organization roles and repository roles based on members’ responsibilities. An Organization Owner SHOULD group members and manage their repo Permissions through GitHub Teams. Organization Owner role SHALL be assigned to a minimal number of 2 and maximum 3 members. Same practice applies to the Repo Admin role. Refer to SCM Best Practices for more information. |
Scorecard checks Token-Permissions and reports if your project's automated workflow tokens follow the principle of least privilege. Example report: Scorecard Allstar raises an issue against the repo when it detects tokens with excessive permission and adds new comments every 24 hours until the issue is resolved. The Organization Owner SHALL periodically audit organization member permissions and token permissions manually before this can be automated. |
| An initial set of metadata is established for gaining security insights into the project. | To start providing insights into your project’s security in both human and machine processable format. | Create SECURITY_INSIGHTS.yml at the root of the repository and ensure schema compliance. The insights SHALL provide header information, project lifecycle, and contributing policy. Example SECURITY_INSIGHTS.yml : OpenSSF: GUAC, Security Insight |
SECURITY_INSIGHTS.yml is found at the root of the repository, and contains metadata for project life cycle and contribution guides. |
| A dependencies policy is published, maintained and followed. | Sets clear guidelines for selecting and maintaining secure dependencies. | Follow Concise Guide for Evaluating Open Source Software to evaluate the dependencies before using them in the project. Publish a dependencies policy to guide contributors on dependency management, using a stand-alone file or CONTRIBUTING.md. Example dependency policy: CNCF: Kubescape, Argo Helm The policy SHALL be added to SECURITY_INSIGHTS.yml section “dependencies” > “env-dependencies-policy”. Example SECURITY_INSIGHTS.yml with dependencies policy: CNCF: Kubescape, capsule. |
SECURITY_INSIGHTS.yml identifies the dependencies policy, the policy provides guidance on dependencies evaluation and maintenance. |
| Direct dependencies are pinned in internet or infrastructure services and applications your project provides. | Ensures that only a known safe version of a dependency is used to protect against malware and credential compromise. | Follow Scorecard documentation to pin dependencies Examples: OpenSSF: Sigstore Fulcio, GUAC |
Scorecard checks dependency pinning and reports whether dependencies are pinned. Example report: Scorecard, Sigstore Fulcio. |
As a project matures and enters into the incubation stage, the project is expected to have more adopters. Additional security needs to be built into the project in order to sustain the secure project development and protect the consumers of the open source project.
Some requirements might be only applicable to some projects, for example, architecture design will apply to projects that have systems integration.
| Security Baseline | Objective | How to Implement | How to Verify |
|---|---|---|---|
| GitHub actions and workflows, if any, are set up securely and remain secure. | To reduce the risk of repository compromise introduced by malpractices in CI/CD pipeline. | GitHub context is an attack surface that leads to script injection. Follow GitHub hardening guide to mitigate the risk. GitHub triggers can be abused to introduce untrusted code into the build process. Follow this article for detailed analysis and practices to safeguard your actions and workflows. Refer to SCM Best Practices for more information. |
Scorecard checks dangerous workflow and reports the finding if dangerous workflow is detected. Example report: Scorecard, Sigstore Fulcio Allstar will raise an issue and add new comments every 24 until the issue is resolved. |
| Static code analysis is run in CI/CD pipeline, if code exists, and critical severity exploitable vulnerabilities MUST be fixed promptly. | To identify vulnerabilities in the codebase you develop, and remediate critical vulnerabilities that are exploitable, ensure your project is adoptable. | Adopt a Static Application Security Testing (SAST) tool to run static code analysis, e.g. CI/CD pipeline. The code analysis runs against the codebase that you develop, identify vulnerabilities and provide recommendations on remediation. Consider Enable CodeQL in your CI/CD pipeline. Examples: OpenSSF:Sigstore Fulcio, Scorecard |
Scorecard checks SASTis used in your CI/CD and reports the finding through the vulnerabilities check. You SHOULD see the report reflects the vulnerability fixes. Scorecard MAY not detect some SAST tools. Example report: Scorecard |
| A security policy is published and followed for vulnerability disclosure and response. | To provide clear guidance on how security findings are reported and the expected response. | SECURITY.md is established as part of the OpenSSF default community health file. It serves as the security policy, and provides generic information about how vulnerabilities are reported to the project. Project maintainers SHALL follow the Guide to Coordinated Vulnerability Disclosure to provide project-specific vulnerability disclosure and response process. GitHub private vulnerability reporting SHALL be enabled at the repo level. The security policy SHALL be added to SECURITY_INSIGHTS.yml under section “vulnerability-reporting”. Examples SECURITY.md: OpenSSF: Sigstore, Scorecard Example SECURITY_INSIGHTS.yml: OpenSSF: GUAC CNCF: capsule, Kyverno |
Scorecard checks security policy existence in a project and reports findings. The SECURITY_INSIGHTS.yml file identifies the security policy file (typically SECURITY.md). Example security insights : OpenSSF: GUAC |
| Data in transit must be protected by cryptographic means. | To protect data from unauthorized access, ensure data integrity, confidentiality and availability. | Cryptographically Protecting Data in Transit, in Use and at Rest provides detailed rationale behind the baseline and implementation guidance. TAC project lifecycle governance process SHALL be used if encryption is not achievable. |
Use curl and openssl to verify the TLS protocol version, cipher and certificate chain for HTTPS traffic. |
As a project matures and progresses towards graduation, it gains wider adoption. To prepare for its general availability and sustainability, additional security measures beyond the incubation baseline are necessary to safeguard project consumers.
| Security Baseline | Objective | How to Implement | How to Verify |
|---|---|---|---|
| Architecture design is created with up-to-date security controls for software-based projects. | Enhance security posture and reduce vulnerabilities. | Design Doc at Google is a good reference SECURITY_INSIGHTS.yml SHALL be updated under “security-artifacts” > “other-artifacts” to include architecture design. The design SHALL be maintained to be consistent with the implementation. | The SECURITY_INSIGHTS.yml file identifies the architecture design that provides information for the system design and security controls. |
| Project has no medium or higher severity vulnerabilities from SAST scan. | To ensure your project is safe for wide adoption and protect OSS consumers. | Continue to run SAST scan in your CI/CD pipeline, validate the vulnerabilities findings, remediate exploitable vulnerabilities in a timely fashion. Suppress findings that are not exploitable to reduce the false positives. | Scorecard checks SAST is used in your CI/CD and reports the finding through the vulnerabilities check. You SHOULD see the report reflects the vulnerability fixes. Example report: Scorecard |
| Publicly known vulnerabilities of critical severity are fixed promptly. Fixes are released promptly. Publicly known vulnerabilities of medium or high severity are fixed. Fixes are released within 60 days. |
To protect your software from known vulnerabilities. To protect downstream consumers from vulnerable software via transitive dependency. |
Follow Scorecard instructions to use a tool to automatically update dependencies. Follow Scorecard instructions to fix vulnerabilities or suppress warnings when the vulnerabilities are not exploitable. You can also add GitHub dependency review for PR workflows. There's a 'warn-on-openssf-scorecard-level' parameter that you can configure to a custom Scorecard threshold to raise warning on the Scorecard checks that are important to the project. |
deps.dev provides insights into your projects’ dependencies including transitive dependencies, the security advisories relevant to your project, and your projects’ Scorecard report at a high level. Example deps.dev insights: Sigstore Rekor |
| Merging into the main branch requires a minimum of one maintainer approval (not including the PR submitter) and all CI/CD status checks passing. | Reduce the risks of malicious code injection into the repo, and unintentional errors that impact system availability | An Organization Owner or Repo Admin creates a branch protection rule to enforce pull request approval by at least two maintainers. TAC project lifecycle governance process SHALL be used for exception approval when the project does not have enough maintainers. |
Scorecard checks Branch Protection and assigns a score at least 8 out of 10 when your project is enforcing this protection. Example report: Scorecard |
| Source repository is free of generated executable artifacts. | To eliminate the risks of maliciously subverted executables, ensure that generated executables are reproducible from source code | Remove the executable files from the source repository, always build from source code. | Scorecard Binary-Artifacts check reports if your project has executable artifacts in the source repository. Example report: Scorecard Allstar verifies that binaries are checked into the source code repo for testing purposes, these binaries can be exempted from Scorecard binary check via Maintainer Annotation. |
| If release artifacts are created, SBOM is generated and distributed as a release artifact. | To provide accurate and complete inventory of the software version, license, dependencies and vulnerabilities to enhance supply chain security, in both human and machine processable format. | Refer to OpenSSF SBOM Everywhere SIG for the importance of SBOM generation, consumption and process improvement. Generate SBOM’s in your project’s GitHub release workflow, ensure minimal data fields recommended by NTIA are populated. Example SBOM: OpenSSF: GUAC SPDX CNCF: Kyverno CycloneDX SECURITY_INSIGHTS.yml SHALL be updated under “dependencies” > “sbom” to include all the build SBOM’s. TAC project lifecycle governance process SHALL be used for exception approval when there is no tooling support to implement the baseline. |
SECURITY_INSIGHTS.yml identifies the SBOM’s. SMOB’s provide information for dependency management, vulnerability management. |
| If release artifacts are created, release artifacts are cryptographically signed. | To ensure the integrity, authenticity, and trustworthiness of release artifacts | Projects SHOULD use Sigstore for signatures. Follow Scorecard Signed-Releases documentation for detailed instructions. Examples signed release: OpenSSF: Sigstore Fulcio, Scorecard |
Scorecard Signed-Releases Check reports that release artifacts are signed. When the Scorecard score is below 8, Allstar will raise an issue and add new comments every 24 hours until the issue is resolved. |
| If release artifacts are created, SLSA v1.0 Build Level 3 artifact attestation is generated and distributed as a release artifact. | To provide verifiable and non-forgeable claims about software origin and build process. | GitHub actions can be used to produce build provenance at SLSA v1.0 Build Level 3. For details, check GitHub artifact attestation and reusable workflow. To get familiar with SLSA specification and available tooling, visit this workshop material. SECURITY_INSIGHTS.yml SHALL be updated under “security-artifacts” > “other-artifacts” to include attestation information. Examples: OpenSSF: Sigstore Fulcio, Scorecard |
Scorecard Signed-Releases Check reports attestation is generated as a release artifact. When the Scorecard score is > 8 and !=10, Allstar will raise an issue and add new comments every 24 hours until the issue is resolved. SECURITY_INSIGHTS.yml identifies the attestation file. The attestation is verifiable using these instructions. |
| Logging of security events is implemented if your project provides internet or infrastructure service on behalf of the foundation. | To capture security relevant events for incident response. | Application/software level logging SHALL be in place to capture security relevant events, for example authentication. Sensitive information MUST NOT be logged. | Application/software logging is a continuous improvement process to help rapid incident response. The logs are consumed by the project’s maintainers. |
| Monitoring of security events is implemented if your project provides internet or infrastructure service on behalf of the foundation. | To monitor security relevant events for incident response. | If the project provides a service, monitoring SHALL be in place to raise actionable alerts when security relevant events meets pre-defined thresholds, for example host level firewall configuration is changed. | Manual review. |
| If your project provides internet or infrastructure service on behalf of the foundation, an initial security audit is conducted. Audit findings are addressed. | To identify and remediate the vulnerabilities in the internet service. | Security audit SHALL be funded through the TAC TI funding process. SECURITY_INSIGHTS.yml SHALL be updated under “security-assessments” with a link to the audit report. |
SECURITY_INSIGHTS.yml identifies the security audit report. The report provides details of the audit methodology, findings and recommendations. |
Additional security MVP baseline on top of incubating baseline:
| Security Baseline | Objective | How to Implement | How to Verify |
|---|---|---|---|
| Publicly known vulnerabilities of critical severity are fixed and released in coordination with project consumers promptly. Publicly known vulnerabilities of medium or high severity are fixed and released in coordination with project consumers within 60 days. |
To protect your software from known vulnerabilities. To protect downstream consumers from vulnerable software via transitive dependency |
Continue to use automatic dependency update tools to actively manage vulnerabilities. Leverage OSV to identify and remediate vulnerabilities. Keep the project security policy up to date, follow the vulnerability disclosure and response process consistently. Subscribe to OpenSSF SIREN to receive real-time threat intelligence updates to stay connected with both open source community and OSS consumers. If tooling support is available, Collaborate with OpenSSF vexctl to generate VEX statements when reported vulnerabilities are not exploitable, and update SECURITY_INSIGHTS.yml. |
Monitor the vulnerabilities reported through the project vulnerability disclosure process and follow the response process. Monitor your project’s Scorecard report actively, especially vulnerabilities check results to validate vulnerabilities and take actions accordingly. SECURITY_INSIGHTS.yml identifies the VEX statements. The statements provide evidence that the project is not subject to the vulnerability exploit. |
| If your project provides internet or infrastructure service on behalf of the foundation, a security audit is conducted on as-needed basis following the initial audit. Audit findings are addressed. | To keep the project up with the evolving threat landscape. | Security audit SHALL be funded through the OpenSSF TAC TI funding process. SECURITY_INSIGHTS.yml SHALL be updated under “security-assessments” with a link to the new audit report. |
SECURITY_INSIGHTS.yml identifies the security audit report . The report provides details of the audit methodology, findings and recommendations. |
- Rust
- .rs for source files
- .toml for the Cargo configuration files
- Cargo is Rust's build system and package manager.
- Go
- .go for source files.
- C#:
- .cs for source files
- .csproj for project files
- Java
- .java for source files
- .class for compiled bytecode files
- .jar For Java archive files
- Swift
- .swift for source files.
- Python
- .py for source files
- .pyc for compiled bytecode files
- JavaScript
- .js for standard JavaScript files
- Common JavaScript File Extension provides a comprehensive list.
- C
- .c for C source files
- .h for header files.
- C++
- .cpp, .cxx, .cc, .C (uppercase C, less common) for C++ source files
- .hpp, .hxx, .hh, or .H for C++ header files.
- .h is also commonly used for C++ header files in projects that are written in both C and C++.
- Assembly
- .asm for source files
- The file extensions for Assembly language can vary more widely depending on the target platform and the assembler being used.
The 2FA setting changes are captured in the GitHub audit log. The enterprise audit log is being monitored and alerted on using Linux Foundation DataDog and Jira. Two OpenSSF staff members are the enterprise owners, and they are the first responders to the alerts.
When 2FA is disabled in GitHub Enterprise or an organization, an alert MUST be raised for enterprise owners and organization owners to respond and re-enable 2FA. Enterprise owners MUST confirm 2FA enablement by verifying the event in the audit log.
- Enterprise account
- Event
- Disable 2FA: business.disable_two_factor_requirement
- Enable 2FA: business.enable_two_factor_requirement
- Response:
- DataDog will trigger an alert when detecting the above events
- OpenSSF staff with the enterprise owner role MUST take action to triage and restore the setting, following change management process
- Event
- Organization
- Event
- Disable 2FA: org.disable_two_factor_requirement
- Enable 2FA: org.enable_two_factor_requirement
- Response:
- DataDog will trigger an alert on detection of the above event
- OpenSSF staff MUST take action to triage and restore the setting in “ossf” org, following change management process
- OpenSSF staff MUST take action to inform the owner of the impacted organization and support restoring 2FA
- Event
The Secret Scanning and Push Protection setting changes are captured in the GitHub audit log. The enterprise audit log is being monitored and alerted on using Linux Foundation DataDog and Jira. Two OpenSSF staff members are the enterprise owners, and they are the first responders to the alerts.
When Secret Scanning and Push Protection features are disabled in GitHub Enterprise or an organization, an alert MUST be raised for enterprise owners to respond and coordinate with organizations owners or repo admins to restore the settings. Enterprise owners MUST confirm feature enablement by verifying the event in the audit log.
- Disable Secret Scanning and Push Protection
- Event
- Enterprise account
- business_secret_scanning.disable
- Repository
- repository_secret_scanning.disable
- repository_secret_scanning_push_protection.disable
- Enterprise account
- Response
- DataDog will trigger an alert when detecting the above events
- OpenSSF staff with the enterprise owner role MUST take action to triage, identify where the setting has changed, and restore the setting in collaboration with organization and repo admins, following change management process.
- Event
- Enable Secret Scanning and Push Protection
- Event
- Enterprise
- business_secret_scanning.enable
- From repository
- repository_secret_scanning.enable
- Enterprise
- Event
Cryptographically protecting data in transit ensures that data transmitted over networks or between systems is protected from unauthorized access, man-in-the-middle attack (MitM), tampering of data and systems, and data breach. These attacks lead to disruptions to critical infrastructure operations, for example, health care, utilities, banking and telecommunications. Businesses and individuals suffer from financial and reputation losses, regulatory compliance consequences and intellectual property loss. Recent ransomware attack on US hospital networks endangered patients’ health.
Here are common use cases for encrypting data in transit to protect the data confidentiality and integrity:
- Secure Web Communications (HTTPS): Web traffic is protected via HTTPS to ensure that confidential information, such as login credentials, financial transactions, and personally identifiable information (PII), is protected from tampering and loss.
- Secure Messaging: Applying cryptography to emails and instant messages ensures that the content of messages remains confidential and cannot be read or altered by unauthorized parties during transmission.
- File Transfers: Applying cryptography to data during file transfers (e.g., using secure file transfer protocols like SFTP or FTPS) ensures that files exchanged between systems or individuals are protected from tampering and loss.
- Database Connections: Applying cryptography to database connections (e.g., using TLS/SSL) ensures that data transmitted between applications and databases remains confidential and secure, preventing unauthorized access and data breaches.
- Remote Access: Applying cryptography to remote access sessions (e.g., using VPNs or SSH) ensures that data transmitted across networks is protected from MitM.
- API Communications: Applying cryptography to API communications ensures that data exchanged between different software applications or services over the network is protected from MitM, data loss and tamping.
To protect data confidentiality, integrity, and authenticity during transmission over networks or between systems, applying cryptography to data in transit is critical.
When using cryptographic libraries, refer to section “Use basic good cryptographic practices” in OpenSSF Best Practice Badge.
HTTPS MUST be used for API communications. TLS 1.2 and above protocol SHALL be used.
You can access GitHub repositories over HTTPS. If you have not installed GitHub CLI, you need to use a personal access token to run commands against GitHub. HTTPS access allows you to access GitHub API, or run Git commands using repositories HTTPS URL.
You can use SSH to authenticate to GitHub from the command line to work on your repositories. The setup is one time effort generating a SSH key pair, uploading a public key to GitHub, and pointing Git to the remote SSH URL. With SSH keys, you can connect to GitHub without supplying your username/password or personal access token every time when you log in to commit code, clone repo, etc. DSA SHALL NOT be used to generate SSH keys. The following algorithm SHALL be used: - RSA (Rivest-Shamir-Adleman):
- Minimum recommended key length: 2048 bits
- Higher security: 3072 bits or 4096 bits
- ECDSA (Elliptic Curve Digital Signature Algorithm):
- Minimum recommended key length: 256 bits
- Higher security: 384 bits to 521 bits
- Ed25519:
- Fixed key length: 256 bits
The most practical way to protect data during execution is with Confidential Computing techniques. Confidential Computing protects data in use by performing computation in a hardware-based, attested Trusted Execution Environment. Typically this entails memory encryption and sometimes integrity features controlled by a restricted mode of a CPU, GPU, or other processor. Features are available across different levels of granularity to isolate regions of a process, the entirety of a process, and the entirety of a virtual machine. Isolating the smallest region limits exposure, see: Trusted Computing Base
Other means of protecting data during execution exist such as fully homomorphic encryption (FHE) and multi-party computation (MPC). These cryptographic techniques do not rely on hardware techniques for their security, but they do have nuanced limitations and compute costs that restrict their utility to certain case. For more on the comparison between Confidential Computing and FHE see: Confidential Computing and Homomorphic Encryption.
Open source software and guides are freely available through the Confidential Computing Consortium.
For data at rest, follow the instructions from the storage solutions for encryption practices
curl is a powerful CLI tool to troubleshoot and observe details of HTTPS traffic, including the TLS handshake and certificate information. For example the following command provides insights into a HTTPS GET request and response, including the x.509 certificate details, TLS protocol and cipher, etc. This article provides a comprehensive overview of x.509 certificates.
curl -vI https://google.com
-v: verbose mode, provides more details about the HTTPS response, including the SSL handshake and server side certificate information.
-I: Fetches the headers only (HEAD request), not the body of the response.
openssl is another powerful CLI tool to create CSR’s and troubleshoot certificate related issues, especially issues along the certificate chain. For example, the following command provides details of the certificate chain for google.com, including the server certificate, the intermediate cert and the root CA that issues the intermediate cert.
openssl s_client -showcerts -servername google.com -connect google.com:443 </dev/null