2023-06-21-TAC-LfnProjectSecurity.pptx

Share your community's best practices that might be applicable to other projects.

Vulnerability Reporting

  • Create formal bug reporting process for the project.

Demonstrate Security Awareness

 

  • Linux Foundation security community

Practice Secure Lifecycle Management (per release)

  • Retire technical debt.
  • Include vulnerability management.
  • Identify and remove unmaintained code from release package.
  • Upgrade dependencies (libraries, databases, language versions.)
  • Interface security (APIs, GUIs, Portals.)
  • Remove all secrets from code.

  • Goal for LFN projects: create an LFN security cookbook that documents how security best practices and tools can be implemented and used across LFN project.

  • Starting point: ONAP implementation of Security Best Practices, LFX security.

Documentation

  • Provide security transparency to the users of the open source code.
  • Known open vulnerabilities in project code and dependent packages.
  • Vulnerabilities closed in the release by fixing code and upgrading packages.
  • Secure and resilient configuration settings
  • Integration points with external security system
    • Certificate Authority (CA)
    • Certificate management protocol support
    • LDAP
    • OAuth Authorization Server
    • Log management systems
  • Language version dependencies
  • Third party component and version dependences
    • databases such as Cassandra
    • messaging such as Kafka

CI/CD best practices

  • Automate rejection of insecure merges (planned PoC in ONAP)

Architecture

  • Include logging of security events in the project.
  • For stand-alone projects: integrate authentication and authorization into web interfaces and APIs.
  • Support confidentiality on all interfaces. For HTTP, this typically means supporting TLS 1.2+.
  • Where containers are used: follow the CIS benchmarks, such as the Docker benchmarks.
  • Where K8S is used: follow the CIS Kubernetes benchmarks.

Supply Chain Security

  • Secure the commit process to prevent unauthorized code from being included in an open source project
  • Digitally sign all code produced by the project using an X.509 code signing cert issued by a public certificate authority (CA).
  • The Linux Foundation has a secure signing process.
  • Create an SBOM for each application produced by a project team.
  • Use SPDX, CycloneDX or SWID for SBOM format.
  • Digitally sign the SBOM with an x.509 signing certification issued by a public CA.
  • SBOMs can be automatically generated in the CI/CD pipeline using a software composition analysis tool.

Software Bill Of Materials (SBOM)

Integrate security testing in CI/CD

Test TypeDescriptionExample ToolsLF Provided Tools
Static Application Security Testing (SAST)Detects vulnerabilities in the code written by the project team. Some SAST tools provide autofix capabilities.

Snyk

Veracode

SonarCloud

Snyk

Blubracket

Software Composition Analysis (SCA)Detects known CVEs in third party package used by the project team in their code.

Sonatype NexusIQ

Veracode

Mend

NexusIQ (ONAP only)

Snyk

Dynamic Application Security Testing (DAST)

Detects vulnerabilities in a running application by simulating attacks to all interfaces and examining its running state, and its responses to the simulated attacks.

Requires the project team to create a traffic file that can be replayed in the pipeline.

AppScan??
Container Scanning

Detects vulnerabilities in container base images and open source dependencies used in base images and Dockerfile commands.

Some products include autofix capabilities.

Snyk

Aqua/Trivy

JFrog Xray

StackRox

Snyk
Code Coverage Testing

Verifies and validates code quality by evaluating the amount of code executed by automated tests.

SonarCloud??
Code Quality

Measures the quality of the code produced by the project team. Code quality measures include maintainability, clarity, testability, portability, robustness, reusability, complexity, safety and security.

Never hardcode secrets in code.

SonarCloud??

Other tools

  • Remote attestation (SEDIMENT)
  • 3rd party API checks

Managing dependencies

  • Direct dependencies are straightforward.
    • Upgrade direct dependencies to the latest supported version with each release.
    • Prioritize upgrading direct dependencies with effective vulnerabilities.
      • An effective vulnerability is one that can be executed by the application containing it.
      • Not all vulnerabilities in a package are in code that is used by the application.
    • Prioritize upgrading direct dependencies on deprecated versions.
    • Prioritize upgrading direct dependencies containing vulnerable dependencies.
    • Dependencies with zero-day critical vulnerabilities may require upgrades and emergency releases. A good example is Log4J.
  • Transitive dependencies are more difficult.
    • May be resolved by upgrading to a newer version of the direct dependency containing it.
    • Some transitive dependencies can be upgraded independent, but this requires more testing.
  • How to automate the mitigation?
    • Some container scanning tools can automatically upgrade open source dependencies used in container base images.


  • No labels