Path to Secure Linux Platforms

Once a vulnerability is detected, it takes 97.8 days on average to fix it

Companies relying on open source software are growing increasingly aware of how important it is to understand all its dependencies.

Your software solution is only as strong as its weakest link. 73% of organizations are searching for best practices to continually improve and evolve software security practices. This white paper will focus on how companies relying on Linux platforms can take a proactive approach to security.

Security is cyclical by nature. Best practice for managing vulnerabilities involves identifying, addressing, testing, evaluating, improving on the process, and restarting it. Done right, it is a never-ending cycle of continuous improvement.

Industry polls report that about 40% of companies don’t have a plan or policy for the handling of CVEs. If that describes your company, this is the moment to change that. If you do have a plan for addressing CVEs, then this white paper will help you assess and improve upon your plan.

Open source gives software an edge — and carries inherent risk

As companies increasingly adopt open source software, it’s vital to understand the vulnerabilities that exist and the ripple effect of any dependencies.

Open source is critical to accelerating the software development of intelligent connected devices and embedded systems running at the edge. Yet open source carries inherent risk due to ever-increasing security vulnerabilities. In fact, Positive Technologies reports that 84% of Linux software projects have high-risk vulnerabilities.

As organizations push development boundaries, the inevitable CVE technical debt can mount, and impact project success. Securing your embedded Linux platform is a full lifecycle responsibility, starting with understanding your areas of exposure and impacted code and flowing up to remediation of high-profile CVEs affecting your solution.

WEBINAR POLL 

Who will address critical Linux vulnerabilities?

In our webinar poll, 30% of attendees felt they could fix all critical and relevant vulnerabilities, 39% expected their Semi partner or Linux vendor to handle it, and over 30% admitted to needing help with this or not fixing anything at all.

Security is a continuous vulnerability management lifecycle

Adopt a cyclical process to actively monitor, assess, prioritize, and remediate CVEs throughout the product life cycle.

• Identify and prioritize high-risk CVEs
• Analyze source code to determine whether a CVE impacts your project
• Resolve and mitigate high-risk CVEs
• Manage ongoing platform security requirements

Discover CVEs early and proactively meet them head on

Protect the trust of your users by committing to a lifecycle of continuously improving vulnerability management.

As you can see from the diagram on the previous page, the model we are proposing is cyclical in nature. However, the most logical starting point in the process will be assessment.

1.Assessment

The first steps are to identify your assets, conduct a scan, and report on findings.

Identify Assets

• Your assets will be in the form of a manifest file or an SBOM. An SBOM, especially one in the SPDX format, provides much more detailed information than a manifest file.
• Even though hackers can get their hands on your SBOM if they are motivated enough, it’s not advisable to share your SBOM publicly.

Scan

• There are a number of scanners out there, but not all scanners are created equal. Check out Wind River’s white paper, “10 CVE Scanner Must-Haves for Security Success” to help you evaluate what makes a good scanner. A round up of those top 10 are listed at right.

Reporting

• Reports should be customizable to focus on your most important attack vectors, whether threats are network, adjacent, local or physical.
• Ideally your report highlights vulnerabilities that are relevant to you with easy-to-digest data visualizations such as charts and tables.
• Like most scanners, Wind River reports CVSS scores on two versions: v2 and v3. If you’d like more details on why the ranking HEX 6C9694 and criticality can change significantly between v2 and v3, look at the specifications documents at www.first.org.

Prioritize through triage by gauging the exposure

2. Prioritization

Next, evaluate the threats to the success of your solution by gaugingexposure and adding context.

Gauge Exposure

• Gauge the exposure that the vulnerability actually impacts with your solution to determine everything that may be affected.

Add Threat Context

• Before you go through the whole development cycle to implement a fix, evaluate whether your application might already mitigate or remove the vulnerability from impacting your solution.
• Develop a triage process that each team can use to evaluate whether the CVE needs to be fixed.

3. Action

This is when you do what is necessary to fix your solution. Once you’ve prioritized your solution, you need to determine how you want to act on the issue. You have a choice — you can develop a remediation plan (fix it), mitigate against further complications (reduce the severity or seriousness of the event), or accept the risk (do nothing).

Remediate

• When you remediate, you patch by either back porting a fix from a recent software version that’s applied to an older version of the same software, or by up-revving it to a more current version of the package that doesn’t have the issue in it.
• Depending on the age of what you’re maintaining, you may need to back port the fix from a later version into your solution.
• Alternatively you can up-rev it, by downloading the package and then porting the whole packet into your solution — however you’ll need to up-rev the supporting packages that go with that solution too. Depending on how many dependencies your packages have and then dependencies those may have, it may be simpler to back port instead of up-rev — it just depends on your solution.

To achieve and maintain platform stability you need a solid CI/CD pipeline implemented internally or managed by a partner. Your pipeline should incorporate regular smoke tests of your CVE fix, and ongoing testing — perhaps a nightly integration test, a weekly system test, and a monthly full test. Specific to the coding of the CVE fix, your pipeline needs to integrate the fix into Linux and all your layers, automate the architecture that you’re looking for, automate testing, review tests with partners and peers, then merge those components into whatever repo(s) your organization uses.

Once your developers have integrated your CVE fix into the pipeline, you’ll need to make sure your open source automation server (for ex. Jenkins) can present that information for consumption to your organization and to your customers to prove that the CVEs have been resolved.

The good news is, there are partners who can help you manage all of this. Please reach out to Wind River to see how we can support you.