Data Protection

Want Cyber Insurance? Better get patching!

viviandufour, , , Leave a comment
Image from https://unsplash.com/photos/bq31L0jQAjU

Want Cyber Insurance? Better get patching!

Managing the technology stack and known vulnerabilities is becoming a key criteria for  cyber insurance pay outs

Open source software has once again made the headlines following warnings to organisations about the release of a new version of OpenSSL. Released on 1st November 2022, the new version patched vulnerabilities in version 3.0 and above of the nearly ubiquitously used cryptographic library for encrypting communications on the Internet.

The OpenSSL Project team took the unusual step of pre-warning organisations five days ahead of the 1st November release date that a critical update was being issued to address the vulnerabilities. This came as a surprise to many as the OpenSSL library rarely has critical vulnerabilities, but due to its popularity and widespread use, organisations were advised to be cautious and to prepare. 

Based on the assessment by the OpenSSL team, the vulnerabilities can be exploited and trigger data leakage or remote code execution. It is hard to predict the potential damage and risk of these vulnerabilities, which is why it’s vital for organisations to act swiftly, determine any use of the affected OpenSSL and patch immediately if they are exposed to the vulnerabilities. However, as these vulnerabilities were classified as “high severity” and not critical as initially thought, widespread exploitation is not expected. 

Open Source the foundation of modern software

The benefits of open source software are numerous and well known, so let’s be clear open source is not the problem – our ability to learn from the past is. 

There have been a couple of big open source incidents in the last year that have sent shock waves through the cyber security world. Firstly, the vulnerability in the widely deployed Log4J component, and now this new vulnerability in OpenSSL. This is only the second such flaw ever found in the open source encryption project. The first was Heartbleed.

The December 2021 zero-day vulnerability in the Java logger Log4J, known as Log4Shell, was characterised by many security experts as the single biggest, most critical vulnerability of the last decade. If left unpatched, attackers can hack into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage, not least to brand reputations. 

Unfortunately, a situation that specialty insurer Crum & Forster, owned by Fairfax, know all too well after falling victim to the hacking group known as RansomHouse. Despite widespread news coverage of the Log4shell vulnerability, which was revealed in December 2021, it appears the insurer was still vulnerable. 

The breach at Crum & Forster was first discovered on 22nd July 2022. The hacking group were able to exploit an unpatched system, resulting in a total of 1.7 gigabytes of sensitive data being released, including medical information, insurance policies, employee data, and customer lists. 

Crum & Forster are by no means an isolated case, there are many examples over the years of companies falling victim to known vulnerabilities. 

History repeating itself

The Heartbleed vulnerability, discovered in 2014, impacted hundreds of thousands of web and email servers worldwide. Among the many systems confirmed to be affected were large organisations such as Yahoo, Eventbrite, and even the FBI’s own website. Many of the big companies confirmed to be affected were able to get their ducks in a row and patch before anything severe happened. 

Others weren’t so quick off the mark and hackers were able to exploit the vulnerability in several cases. The Canadian Revenue Agency was one of the many victims that suffered a breach as hackers exploited the Heartbleed vulnerability. The breach resulted in the theft of hundreds of social ID numbers in a six-hour period before the Canadian Revenue Agency realised and removed public access to its online services. 

In the aftermath of a breach, companies are quick to express that lessons will be learnt. Unfortunately, in a case of history repeating itself, the Canadian Revenue Agency was once again hitting the headlines. In 2017, just 3 years after Heartbleed, the company had to shut down its website for filing federal taxes due to falling victim to the open source Apache Struts2 vulnerability. 

Fail to patch, plan to fail 

Several years on from when Heartbleed was discovered and a patch issued, there are still servers harbouring the Heartbleed vulnerability. In November 2020, a security researcher at the SANS Internet Storms Centre discovered that over 200,00 machines are still vulnerable to Heartbleed. The news cycle may have moved on but that doesn’t mean unpatched vulnerabilities have disappeared. 

Too many headlines are showing that hacks have one thing in common, they are caused by a known vulnerability within an open source component. 

A well know example is the Equifax data breach in 2017, which remains one of the largest cybercrimes related to identity theft. The private records of 147.9 million Americans along with 15.2 million British citizens and approximately 19,000 Canadian citizens were compromised in the breach. 

A key security patch for open source software Apache Struts was released by the Apache Software Foundation on 7 March 2017 after a security exploit was found. All users of the framework were urged to patch immediately. 

For one reason or another, the patching process within Equifax completely broke down, resulting in vulnerable systems being left open to compromise. Subsequent scans conducted by the Equifax IT department to identify any vulnerable systems appears to have failed and, as the saying goes, the rest is history. 

The cost of downplaying security

Recent estimates suggest the 2017 Equifax data breach cost the company at least $1.38 billion, with some sources suggesting the final bill could be closer to $2 billion. The root cause of the data breach was the failure to patch a known open-source web application security flaw. The company effectively left the door open for cyber criminals to walk in and wreak havoc.

In the aftermath of the breach Equifax was condemned for its lax security posture, shambolic emergency response and poor leadership, which led to many senior executives being accused of corruption. The Equifax breach investigation highlighted several security lapses that allowed attackers to enter, allegedly secure, systems and exfiltrate terabytes of data. 

More than five years on, the Equifax data breach remains a cautionary tale in failing to manage cyber security risk effectively and lacking the tools and processes to implement a robust vulnerability and patch management regime.  

Cyber Insurance: prove it or risk losing it

Cybercrime has become a highly lucrative operation; it is not going away and is only set to worsen as companies continue to engage digital technology. Many have taken out cyber insurance to insulate themselves from the punishing costs of cyber-attacks and data breaches. 

However, companies across the world are likely to face increases in the cost of insurance as the number of claims increase year on year. According to research conducted by FitchRatings, US claims volume has risen 100 percent annually over the past three years. 

In part as a result, the cost of cyber insurance has risen steeply in 2022 in both the US and the UK. According to Marsh, the UK cyber insurance market experienced a pricing increase of 102% year-over-year in the first quarter of 2022.

As a result of rising claim costs, the insurance industry is tightening their qualifying requirements and limiting their coverage. Cyber insurers now require organisations to provide information about their security controls if they want coverage. This can include technical, procedural, and human controls. 

Keeping track of your open source exposure

Software Bill of Materials (SBoMs) are an emerging approach to keeping track of your software dependencies, both open source and commercial. SBOMs provide the ingredients list to understanding what code exists within the applications that your business relies upon. 

Only by understanding what exists inside applications can organisations evaluate their exposure to risk. Used effectively, SBOMs enable companies to evaluate and target remediation efforts. But most importantly, companies won’t be blindsided when the next big open source vulnerability is announced. 

Known vulnerabilities are your responsibility 

Many cyber insurers have tightened their standards and are no longer paying out for breaches that have resulted from a known vulnerability. This should serve as a sharp wakeup call to boardrooms that deploy technology, with little thought to the security implications. If companies want to ensure they continue to receive all the benefits of their policy, it’s vital that they have a rigorous patch management system. Corporates may have short memories when it comes to known vulnerabilities but, as the evidence shows, cyber criminals do not. 

Companies must increase visibility and transparency of the components in their open-source software and applications if they are to stay one step ahead of cyber criminals. Without continuous management of your governance, risk, and compliance of open source your company is walking a tight rope, without a safety net. Those that fail to learn from history are doomed to repeat it.

Want Cyber Insurance? Better get patching!

Visibility is vital if we are to improve safety and trust in open source

viviandufour, , , , Leave a comment
Image shows an observation deck, but the panorama is veiled behind white light or mist showing blank skies. Do we know or see what we are building in our digital world?

Photo by Kate Trysh on Unsplash

Recent high profile cyber security incidents have reinforced the importance of cleaning up the open-source software supply chain. From Heartbleed to the Apache Software Foundation’s Log4j vulnerability, these highly publicised incidents have exposed the threats associated with the software supply chain.

Open source security vulnerabilities are nothing new. Heartbleed was a security bug in the OpenSSL cryptography library that affected many systems. Similarly, Log4Shell is a severe vulnerability, however in the case of Log4j the number of affected systems could well run into potentially billions. Many cybersecurity experts have characterised Log4Shell as the single biggest, most critical vulnerability of the last decade.

These incidents have brought into sharp focus the risks and galvanised a range of responses at national and international level. It even prompted the White House to convene an Open Source Software Security Summit in January that was attended by leaders from global technology companies including Google, Meta, Apple, and Cisco. Members of the open source community were also represented at the summit, as well as US government agencies, including the Cybersecurity and Infrastructure Security Agency, the National Security Council and the National Institute of Standards and Technology.

The gathering may have been precipitated by the Log4Shell vulnerability, but the wider context was clear. How do we ensure source code, build, and distribution integrity to achieve effective open source security management?

Open source under the microscope

Technology companies have been using open source for years as it speeds up innovation and time to market. Indeed, most major software developments include open source software – including software used by the national security community.

Open source software brings unique value, but it also has unique security challenges. It is used extensively, however, the responsibility of ongoing security maintenance is carried out by a community of dedicated volunteers. These security incidents have demonstrated that the use of open source is so ubiquitous that no company can blindly continue in the mode of business as usual. Recent research showed that 73% of applications scanned have at least one vulnerability[1]. These can be buried deep in the open source software supply chain that software-driven businesses rely on for basic functionality and security to accelerate their time to market.

The known unknown

The concept of known knowns, known unknowns and unknown unknowns has been widely used as a risk assessment methodology. When it comes to cybersecurity and the voracity of threat actors to exploit vulnerabilities, it is a useful analogy.

Let’s take Apache Log4J as an example. Companies often create products by assembling open source and commercial software components. Almost all software will have some form of ability to journal activity and Log4j is a very common component used for this.

How do you quickly patch what you don’t know you have?

Java logger Log4j 2 – A zero-day vulnerability

Log4J was originally released in 2001, and over the last 20 years it has been used in billions of software developments and applications across the world. For logging incidents within software, Log4j is used by everything from the humble 404 error message, gaming software such as Minecraft, and Cloud providers such as iCloud and Amazon Web Services, as well as for all manner of software and security tools.2 On 9 December 2021, the zero-day vulnerability in the Java logger Log4j 2, known as Log4Shell, sent shockwaves across organisations as security teams scrambled to patch the flaw. If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage, not least to brand reputations.

However, herein lies the problem. How do you quickly patch what you don’t know you have?

Often in the race to innovate, the first thing sacrificed is up-to-date documentation. Without it how does a company know if Log4J is integrated within its application estate, let alone know if it has been previously patched.

Improving safety and trust when speed is of the essence

If we are to increase safety and trust in software, we must improve transparency and visibility across the entire software supply chain. Companies should have the ability to automatically identify open source components in order to monitor and manage security risk from publicly disclosed vulnerabilities. A software bill of materials (SBOM) should be a minimum for any project or development. Without such visibility of all component parts, security teams cannot manage risk and will be unaware, and potentially exposed, to dangers lurking in their software.

Case study – Full Visibility within an Hour

To give an example; one of the largest UK based financial services company with millions of customers across the world discovered it had Log4J embedded within dozens of in-house developed software projects. Having seen the first reports of the vulnerability at the start of the business day, within an hour the security team had identified projects using Log4j and were able to start work on follow up activities. By the end of the day, the entire business had a concise list of projects at risk, some of which were already remediated.

How was this achieved?

The company had automated tooling integrated into their software development environment with comprehensive component security. This enabled them to quickly identify those software projects which depended on the affected log4j component.

This visibility allowed the company to devise remediation plans to mitigate the risks of the vulnerability in Log4J. The company was able to target valuable resources across multiple locations to ensure fixes were applied quickly to critical business applications within just a couple of hours. While they were implementing an action plan based on the organisation’s use of Log4j, some of its competitors without such comprehensive tools were still in the information gathering stage.

Innovating securely

As organisations continue to innovate at pace in order to reduce time to market, the reliance on open source software continues to increase. However, when the security of a widely-used open source component or application is compromised, every company, every country, and every community is impacted.

The White House has taken an important first step in trying to identify the challenges present in the open source software supply chain and encourage the sharing of ideas on ways to mitigate risk and enhance resilience. Organisations can and should take advantage of the many benefits that open source software can deliver, but they must not do it blindly. Ensuring you know the exact make-up of your technology stack including all the component parts is an important first step. Choosing discovery tools that have the widest comprehensive coverage is important, and so too is the flexibility to grade alerts so that only the most pressing threats are highlighted. This avoids ‘alert fatigue’ and enables security teams to focus resource where it matters most, putting organisations in a good position to act fast when vulnerabilities are discovered.

Hackers faced with stronger security defences will continue to turn their attention to the weaker underbelly of the software supply chain. Now is the time for organisations to implement integrated and automated tooling to gain comprehensive risk control of components in their open-source software supply chain. Only by increasing visibility, coverage of known unknowns and transparency can companies stay one step ahead.

1 Meterian research from aggregated and anonymised data of 2044 scanned software applications in 2020.

2 “What is Log4j? A cybersecurity expert explains the latest internet vulnerability”, The Conversation, Dec 21, 2022, https://theconversation.com/what-is-log4j-a-cybersecurity-expert-explains-the-latest-internet-vulnerability-how-bad-it-is-and-whats-at-stake-173896

Visibility is vital if we are to improve safety and trust in open source

Urgent and Critical: Remote Code Execution in Apache Log4j needs immediate upgrade

viviandufour, , , , Leave a comment

Updated: 31 Dec 2021

5 minute read

This is a call to arms. All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered Apache Log4j vulnerability since its announcement on Dec 9, 2021. Since then several security vulnerabilities in the wild have been discovered.

CVE-2021-44832

Vulnerability Score: 6.6 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: 2.0-alpha7 to 2.17.0 inclusive, except 2.3.2 and 2.12.4.
Fixed in version: 2.17.1

CVE-2021-44228

Vulnerability Score: 10.0 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions before 2.14.1, inclusive
Fixed in version: 2.15.0 but upgrade to 2.17.0 is required because of CVE-2021-45105

CVE-2021-45046

Vulnerability Score: 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) (updated 18/12/2021)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions up to 2.15.0, excluding 2.12.2
Fixed in version: 2.16.0 but upgrade to 2.17.0 is required because of CVE-2021-45105

CVE-2021-45105

Vulnerability Score: 7.5 (CVSS: 3.0 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions from 2.0-beta9 to 2.16.0, inclusive
Fixed in version: 2.17.0


Which systems does this affect?

Apache Log4j is probably the most common library used for logging in the Java ecosystem with over 400,000 downloads from its GitHub project. It is used in Java applications to log system and user activities, so there’s a serious possibility your Java software is using it. It is used, internally, by many other Apache frameworks such as Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo. It is also actively used in many other open source projects, like Redis, ElasticSearch, Elastic Logstash, Ghidra and many others.

Among all these open source components, one needs a special mention: Apache Struts. Yes, it is actively using Log4j. There exists a potential to trigger high-impact attacks against a wide variety of apps and services, similar to the scale witnessed in 2017. At that time, due to the vulnerability exploited in the Equifax megahack, 140 million customers’ data in North America and UK were breached. The latest version of Apache Struts, 2.5.28, uses by default Log4j version 2.12.21, which is vulnerable to this attack. This time, however, the scope for damage could be even wider, as Apache Struts is one of many Apache frameworks that use Log4j. 

The Java ecosystem is in very broad use in enterprise systems and web apps and many mainstream services are likely to be vulnerable. Therefore, software maintainers and developers should pay close attention to this vulnerability. 

This has been preliminary filed as CVE-2021-44228, and a subsequent vulnerability was also flagged, now filed under CVE-2021-45046.


Why does this threat demand an urgent patch?

This vulnerability allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers.

This is actively exploited on the internet now and there is already a simple POC (proof of concept) available on the internet that explains how to do it. 

From https://www.wired.com/story/log4j-flaw-hacking-internet/:

“All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.  […]Minecraft screenshots circulating on forums appear to show players exploiting the vulnerability from the Minecraft chat function. On Friday, some Twitter users began changing their display names to code strings that could trigger the exploit. Another user changed his iPhone name to do the same and submitted the finding to Apple. Researchers told WIRED that the approach could also potentially work using email.”

If you maintain an enterprise system using Java software, you would need to update all affected applications, whether they are maintained directly by your organisation or your supplier organisation.

Within 2 days of the 2017 vulnerability being announced, several systems around the world were breached by exploiting the software weakness.  We do not want more cyber breaches of such scale and all need to react quickly to patch vulnerable systems.


How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using Apache Log4j.  Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries.  If it is using Log4j, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.

If you are a developer and you have access to the code, you can simply execute this command from your terminal:

$ mvn dependency:tree | grep log4j-core | grep compile
[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.12.1:compile

If you see any response lines, check the version: if it’s below 2.16.0 (as in the above example) you may be affected.


My system has the vulnerable log4j library — how can I mitigate the risk?

There is a patched version of the library that resolves the issue.  Released by Apache Software Foundation, the solution is to immediately upgrade log4j to the latest log4j version 2.16.0.  The fixed version is available via Maven. 

If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before:

    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.16.0</version>
    </dependency>

A set of mitigations, specific to the version you are using, are also available on the Apache Log4j website. The Apache Struts team provided specific advice on how to handle the issue.

If you are using an external product that runs with Java, you can also protect your systems by launching the JVM with this special parameter:

-Dlog4j2.formatMsgNoLookups=true

This is useful for tools like Jenkins, where you have control of the installation but you do not have control of the code, but please note that this does not protect against the latest CVE.


What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases. 


Are Meterian applications affected by the log4j vulnerability?

No. We have verified our applications and none are using log4j.  We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components.   

Related references

Urgent and Critical: Remote Code Execution in Apache Log4j needs immediate upgrade

The Rising Role of Cyber Security in Sustainable Development and Growth

Elizabeth LaffoyLeave a comment

Last updated: 07/07/2021

12 minute read

Photo by Kervin Edward Lara on Pexels.com

The topic of sustainability is unmissable at the moment. As the urgency of the situation grows, it continues to demand attention from various sectors and industries within society. You may wonder where the cyber security industry fits into all of this. Whilst traditionally from very different worlds, they are united through the characteristics of constant innovation and the capacity to bring about real change for the better. Certainly, cyber security has a bigger role to play in the overarching battle for a more sustainable world than one may initially think. 

The Industry

As around two thirds of greenhouse gas emissions world wide are associated with burning fossil fuels1, renewable energy is a good place to start. The UK currently has the largest number of offshore wind resources in the world, equating to about 10GW in operation outside of the border2. Infrastructure such as this pushes us one step closer to meeting the UK’s target of reaching net zero emissions by 20502. It’s not just the UK that has set the ball rolling in the fight against greenhouse emissions, our friends across the pond are aiming for no electricity sector carbon emissions by 2035— as outlined by Biden3. So, whilst this growing industry means great things for our hopes of preserving the world we live in, mass investment means it is also shaping up to be a very lucrative market for cyber criminals to direct their efforts towards. Jim Guinn, global managing director for cyber security in energy, chemicals, utilities and mining at Accenture states, “The cybersecurity conversation in the renewable energy engineering and construction business is almost nonexistent today.”3 It is imperative that an industry gaining traction as quickly as this one protects itself with the necessary defense measures against cyber attacks.

How exactly are renewable energy plants made vulnerable to cyber hackers?

As mentioned before, sustainability shares close ties with new innovation. Renewables depend on control systems and distribution networks supported by technology. As many sources of renewable energy, such as wind and solar power are not readily available 24/7 like fossil fuels are— they require storage previsions that are also underpinned by technology4. IoT plays a huge role in the remote monitoring, control and regulation of off-shore wind turbines5. As we know, more than 75% of the code in use that makes these technologies a reality is open source, putting open source components smack bang in the middle of the sustainability conversation. However, older wind farms and their communication systems were never designed with the “security by design” mindset like the IEC 62443 standard6, similar to the GDPR principle7. As stated by Jim Guinn “renewables have lax cybersecurity standards, as they are an industry that may be more focused on building first and leaving cybersecurity as an afterthought”3.

Past attacks

A first example in which renewable energy facilities became victims of cyber attacks was the 2014 DragonFly hack8. The cyber criminal group used Remote Access Trojans (RAT) named Backdoor.Oldrea and Trojan.Karagany to infiltrate energy grid operators, major electricity generation firms, petroleum pipeline operators, and Energy industry industrial control system (ICS) equipment manufacturers located in the United States, Spain, France, Italy, Germany, Turkey, and Poland. The hackers had been present in systems since 2011 before detection. Although reports indicate that the overarching aim of the hack was to gather intelligence, later investigation suggested it also had the capacity to take control of physical systems themselves. 

A second example in which renewable energy facilities have fallen victim to cyber attack was the SPower hack of 2019. Unfortunately, the group gained the title of being the first U.S. provider of solar and wind renewable energy to have been the victim of a cyber-attack. A hacker used a vulnerability in a Cisco firewall to interrupt the connection between sPower’s wind and solar power generation installations and the company’s main command center9. 

More recently, Colonial Pipeline’s hack10– reported on 7th May 2021 fell victim to a cyber attack, highlighting just how seriously energy supplies can be affected by cyber criminal organisations. As a result of ransomware, one of the U.S’ biggest pipelines was forced to shut down operations11. In the subsequently released statement it was revealed that after a 90M bitcoin payout, Colonial Pipeline said that remediation is ongoing and each system is being worked on in an “incremental approach”12. This attack compromised around 45% of the East Coast’s fuel, including gasoline, diesel, home heating oil, jet fuel, and military supplies. Whilst the energy jeopardised in this case was not renewable, Jonathan White, director of NREL’s cybersecurity program office highlighted that “As the penetration of renewable generation and EV charging stations increases in the future, the consequence of a successful attack is likely to be similar in aggregate to those of a successful attack to a natural gas, coal or nuclear plant today”3. Thus, a cyber attack such as the one launched on Colonial Pipeline gives a worrying insight into the potential damage that could be launched on the renewable energy sector. 

Risks for the future

After using the Meterian web scanner to evaluate the security of some major UK energy suppliers, we were able to see that similar issues are being faced. For example, the UK’s biggest supplier of energy, British Gas received a security score of 0 out of a best possible 100. Our report indicates that they currently have components in use that pose a threat to their system, as well as components in use with undeclared licenses.

Again, after scanning https://firstlightfusion.com/, one of the UK’s leading renewable energy suppliers, we found 2 high threat level vulnerabilities and 3 medium threat level vulnerabilities, as well as components in use with undeclared licenses. 

As this sector grows in both relevance and monetary value, there is a need for adequate cyber security that is growing in unison. According to industry growth trajectories, the renewable energy sector is set to become a big target of cyber hackers. As shown in this blog, experts have not been afraid to warn that more needs to be done to reinforce the security of renewable plants. The need is made even more important to protect consumers’ faith in new energy sources that play an important role in our fight against climate change. 

There is some evidence that the tide is changing to benefit the cybersecurity of the energy sector, both traditional and renewable. On 12th May 2021 Biden issued The Executive Order on Improving the Nation’s Cybersecurity13. A few main points from the bill are:

  1. New and more stringent cyber security standards for government purchased software including multi-factor authentication and endpoint detection and response of software.
  2. Suppliers of technology must provide a SBOM (Software Bill Of Materials) that highlights the source of the software (supplier ID) that can be used to perform a risk assessment. This supplier ID can be used to alert high risk software if it is not verified by the digital signature applied to a SBOM14.
  3. There is to be the enforced sharing of intel surrounding cyber attacks, in the hope that the sharing of information will benefit us all. Jennifer Bisceglie, President and CEO of enterprise resilience company Interos Inc., stated that “we live in a world that people are, and companies are very concerned about their brand and reputation”15 and thus are reluctant to admit to cyber breaches. The new bill is set to remove fear of blame and shame and promote collaborative learning and continuous improvement for a safer and stronger society in the digital world.

An automatic, continuous line of defence protecting the open source components in use in renewable energy control systems is one way that Meterian can support the ongoing battle against carbon emissions. Whilst incremental in their support of rapid innovation, open source components are a pressure point to security systems of which cyber attackers are not afraid to make use of.

Visit our homepage to learn more about how Meterian can secure your businesses’ open source components—keeping cyber hackers out and your intellectual property in.

1 “Energy and climate change”. European Environment Agency, 11 May 2021, https ://www.eea.europa.eu/signals/signals-2017/articles/energy-and-climate-change

2 GOV.UK, 6 October 2020, https ://www.gov.uk/government/news/new-plans-to-make-uk-world-leader-in-green-energy

3 Vasquez, Christian. “CYBERSECUIRTY: Biden is eyeing renewable energy. So are hackers”. E&E News, 22 December 2020, https ://www.eenews.net/stories/1063721291

4 Ruhle, Micheal and Trakimavicius, Lukas. “Cyberattacks are the new challenge for renewable energy”. Politico, 18 July 2017, https ://www.politico.eu/article/opinion-cyberattacks-are-the-new-challenge-for-renewable-energy/

5 Taylor-Smith, Kerry. “How IoT can improve the performance of offshore windfarms”. NS Energy, 15 May 2020, https ://www.nsenergybusiness.com/features/iot-wind-power/

6 Freudenberg, Wolf K. “Why windfarms need to step up cyber security”. DNV, https ://www.dnv.com/article/why-windfarms-need-to-step-up-cyber-security-128082.

7 https ://gdpr-info.eu/art-25-gdpr/

8 “Emerging Threat: Dragonfly/ Energetic Bear – APT group”. BROADCOM, 30th June 2014, https ://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=16fb565a-8297-4641-8105-b5d0d4db3ee1&CommunityKey=30643d26-dab8-4c4b-a34e-5f6f02d58ff6&tab=librarydocuments

9 Cimpanu, Catalin. “Cyber-attack hits Utah wind and solar energy provider”. ZDNet, 31 October 2019, https ://www.zdnet.com/article/cyber-attack-hits-utah-wind-and-solar-energy-provider/

10 “Colonial Pipeline confirms it paid $4.4m ransom to hacker gang after attack”. The Guardian, 20 May 2021, https ://www.theguardian.com/technology/2021/may/19/colonial-pipeline-cyber-attack-ransom

11 Galiordi, Natalie. “Colonial Pipeline aims to restore operations by end of the week after cyberattack”. ZDNet, 10 May 2021, https ://www.zdnet.com/article/colonial-pipeline-aims-to-restore-operations-by-end-of-the-week-after-cyberattack/

12 Stevens, Pippa. “Owner of pipeline shuttered by cyber attack aims to restore service by end of the week”. CNBC, 10 May 2021, https ://www.cnbc.com/2021/05/10/colonial-says-parts-of-fuel-pipeline-being-brought-online-aims-to-restore-service-by-end-of-week.html

13 The White House, 12 May 2021, https ://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

14 Brooks, Richard. energycentral, 21 May 2021, https ://energycentral.com/c/ec/cybersecurity-executive-order-requires-new-software-security-standards-synopsys

15 Roby, Karen. MSN, “Expert: Biden’s executive order on cyber security is a good start toward protecting organizations”. 26 May 2021, https ://www.msn.com/en-us/money/smallbusiness/expert-bidens-executive-order-on-cybersecurity-is-a-good-start-toward-protecting-organizations/ar-AAKnd7E?ocid=uxbndlbing

The Rising Role of Cyber Security in Sustainable Development and Growth

Rust— the new language shaking up the open source programming world

bbossolaLeave a comment

Rust is a relatively “new” software language across all the available ones at this time and rising in popularity among developers. Having been voted ‘most loved’ language for the past five years1, it is no wonder that Rust is gaining more attention. Read on to hear why we think Rust is worth your time.

Why a developer should consider Rust

Rust is a system language, along the lines of C and C++, but at the same times it incorporates many of the features of higher level languages, such as:

  • A reliable memory management (without a garbage collector)
  • An extremely low overhead
  • The use of static typing
  • A build design that prioritises performance (at the level of C and C++)
  • The use of a modern package management ecosystem

Remember Go? Rust will almost be faster than Go in run-time benchmarks because it has superior fine-grained control over how concurrency works in terms of threads and shared resources2. 

Additionally, Rust is being considered for use in the Linux Kernel3 by Linus himself, which is no small feat. Rust also supports WebAssembly4, just in case you fancy writing some web stuff 🙂

Rust has also become the ideal candidate for  IoT application development. Labeled as fast, reliable, and secure by Smart Device Management organisation Dwello5 who switched to Rust for their IoT platform. As they build IoT applications, developers have many programming languages to choose from. Some popular options are Java, C, JavaScript and Python. C and C++ are especially popular for device-run code. Another, less popular, option today is Rust, but that is likely to change. Let’s start with the characteristics of any programming language that makes it a good candidate for IoT development.

Application performance is a top priority, especially for code running on devices with minimal CPU and memory resources.  Developers can develop highly performant applications with C and C++, but at a cost. C and C++ developers know all too well the risks and challenges of dealing with bugs related to memory management such as unhandled null pointers and failing to deallocate unused memory.

Another component of a good IoT development language is developer productivity. Productivity is often a byproduct of skills, tools, and programming language abstractions and patterns. Popular programming languages are well supported by development environments. Additionally, developers acquire build tools and skills with time and experience; as a result, language abstractions and patterns are a key consideration with regards to developer productivity.

For those looking for both application performance and developer productivity, Rust is an increasingly popular option. The IoT market size is expected to grow from $250.72 billion in 2019 to $1,463.19 billion by 20276. Clearly, this is an area of the tech world that is only set to expand in influence. Meterian prioritises remaining at the forefront of innovation and supporting languages that have a vital role in ever advancing tech trends.

Why Meterian has decided to add Rust to its supported languages

First of all, Rust is big in open source, so it’s a natural continuation in our mission to support open source. Although security is extremely important in the Rust philosophy, there are vulnerable packages appearing in the wild. The GitHub advisory database7 does not have an entry for Rust (although some advisories do surface here and there) and the NVD database contains only a portion of all the vulnerable Rust components. Meterian is ingesting not only the NVD and other official security Rust databases, but it’s also actively monitoring many Rust open source projects at their source. Our ongoing efforts for getting the optimal coverage of all known vulnerabilities for open source dependencies extends our mission to Rust developers so we can maximise preventative care for Rust coding projects. 

Rust is important to pay attention to because on average every single rust open source project we scanned contains at least 1 vulnerable component that often could be patched.

Sizing up the risks in the Rust ecosystem

Screenshot from: https://www.rust-lang.org/

Rust, like all other modern languages, has an ecosystem of components, called “crates”, that are available from the open source community, which is accessible at crates.io. Although as a Rust developer you will always prefer writing some code from scratch (at the end of the day, this is a system language), it’s highly likely you won’t be reinventing the wheel. As shown on the screenshot from May 6th, over 60,000 crates with over 6.8 billion downloads, this is a significant size.

There’s a good chance that, if you never checked, you have been using a crate affected by a publicly disclosed vulnerability. Unless you are in application security and unless you spend half of your time reading bulletin boards, advisories, mailing lists, you won’t know about it. However, hackers do. They keep an eye on these vulnerabilities and routinely develop automated attacks to exploit them. In fact, hackers have it nailed to a T. The vulnerabilities are made public on open source vulnerability databases, the code is open source, they already have a botnet to run them (maybe even your Amazon Alexa or Google Play). All of a sudden, your shiny new service written with the latest cutting edge technology is vulnerable, and it can be used to exfiltrate confidential user data from your backend!

Let’s assume, for example, that you are using hyper, an HTTP library:

Screenshot taken from: https://www.rust-lang.org/

Since hyper is a relatively low-level library, it’s meant to be a building block for other libraries and applications. It may be a transitive dependency, a crate that is pulled in your code as the result  of another crate that is used. In particular version 0.12.34 of hyper has an interesting vulnerability: it allows an attacker to remotely execute code on the machine where your code is running. Check out this Common Vulnerabilities and Exposures ID CVE-2020-35863 for more details.  This security vulnerability would allow the attacker, for example, to install a very simple bot on your server, open an undetected tunnel and start pulling data from your proprietary system.

This is the beauty of a tool that detects the problem automatically and informs you promptly. We prioritise your time so that you can focus on the solution to remediate the issue, maximising productivity whilst maintaining high standards of open source security. 

What can Meterian do for you?

Sign up for a free account to see how our invisible security platform can work seamlessly in your software development life cycle (SDLC) and auto-remediate vulnerable components.

1 https: //insights.stackoverflow.com/survey/2020#overview

2 Howarth, Jesse. “Why Discord is switching from Go to Rust”. Discord, 4 Feb 2020, https: //blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

3 Salter, Jim. “Linus Torvalds weighs in on Rust language in the Linux kernel”. Arstechnica, 25 March 2021, https: //arstechnica.com/gadgets/2021/03/linus-torvalds-weighs-in-on-rust-language-in-the-linux-kernel/

4 “Why Rust?”, https: //www.rust-lang.org/what/wasm

5 Hiner, Jeff. “We Rewrote Our IoT Platform in Rust and Got Away With It”. Medium, 31 July 2019, https: //medium.com/dwelo-r-d/we-rewrote-our-iot-platform-in-rust-and-got-away-with-it-2c8867c61b67

6 Fortune Business Insights, https: //www.globenewswire.com/en/news-release/2021/04/08/2206579/0/en/Global-IoT-Market-to-be-Worth-USD-1-463-19-Billion-by-2027-at-24-9-CAGR-Demand-for-Real-time-Insights-to-Spur-Growth-says-Fortune-Business-Insights.html

7 https: //github.com/advisories

Rust— the new language shaking up the open source programming world

Open Source Licensing- the Weirder the Better

Elizabeth Laffoy1 Comment

5 minute read

Photo by Sora Shimazaki on Pexels.com

As it’s a requirement that all open source projects are released under at least one open source license, they hold a great deal of influence in how said open source code is used and re-distributed by others. Whilst some licenses can be difficult to make head or tail of due to complicated non-developer language, there are some more relaxed licenses that take the opportunity to have some fun with their requirements. So, to save you doing it, we have assembled our top 5 all time quirky open source licenses to look out for: 

  1. The Beerware License

Written by Danish software developer Poul-Henning Kamp, this license states that if the user thinks the stuff they reuse is worth it they must buy the creator a beer in return. The license’s original notation can be found here. Kamp states his reasoning for the Beerware license is an act of defiance against ‘lawyers trying to interpret freedom’, believing that free open source code should remain free regardless of how much profit is made through its use. Since the requirement is optional, based on the contingency that the user believes the code is ‘worth it’, this license falls under the category of ‘CopyRight only’ licenses. If the requirement were mandatory, the license would be classed as ‘non-free’, and Kamp would most likely be drunk a lot of the time. 

  1. The Chicken Dance License

Otherwise known as the CDL, this license requires employees affiliated with organisations using the open source code to perform ‘The Chicken Dance’ for varying amounts of time, depending on how many units are distributed. The license was created by Andrew Harris with the goal of making “intellectual property far more entertaining to deal with”. Similarly to Kamp, Harries includes himself in wanting fewer lawyers in software – suggesting that the motive behind this wacky license holds strong roots in open source principles of open collaboration. The ‘Chicken Dance’ in question can be found here, but if you can’t master it don’t worry- the license states that moving in a chicken like manor is sufficient.

  1. The Don’t Ask Me About It License 

Perhaps the most simple of the licenses included in the blog, this license simply requests that users do not pester the creator with any issues they may be having with the file. The nod to lack of responsibility is admirable, there is something to be said for wanting to lead a quiet life post software development.

  1. The Hot Potato License

This license states that ‘all rights are reserved by the last person to commit a change to this repository’. Thus, the rights are passed on from person to person infinitely- like a game of hot potato. However, to avoid anyone interrupting this game of hot potato, users are prohibited from making drastic changes to the repository that would do so. It’s a nice touch from the creator to give us all the opportunity to control the rights of such a well known open source license at least once in our life 

  1. The Do What The F*** You Want License

The Do What The F*** You Want License is a ‘very permissive’ license that can be taken as a direct stand against the principle of licencing software in general. Whilst playing by the rules of licencing, this license intends to be a free pass for distribution without any constraints. However, in the attempt of being so liberal, this license actually poses an issue for some major corporations. For example, Google finds the license too unclear to use confidently. As a result, they have banned the use of components under this license completely. However, if you like the look of this license don’t let Google scare you off, wtfpl.net offers guidance on how to make the most of it.

Whilst there is a funny side to open source licensing, failure to stay on top of your business’s license compliance management could be detrimental. A strong defence of these risks, as well as efficient software composition analysis tools will help manage the use of open source in your code base and avoid hefty fines and diminished customer relations. In this way, legal due diligence is an important step in agile development as it allows to ‘push forward’ and remediate any legal obstacles blocking a decision from being made. To read more about cyber due diligence, check out our past blog.

Get in touch with a member of our team to learn more about how Meterian can help your business master License Compliance Management.

Open Source Licensing- the Weirder the Better

Spotify vs Hacker, Round 2: Room for Improvement

Elizabeth Laffoy, , , Leave a comment

5 minute read

We can all admit that as dreary as 2020 has been, it has at least been consistent in its dreariness. One organisation that can definitely vouch for this is music streaming giant Spotify. In true 2020 style, Spotify wrapped up the end of the year with a data breach on November 12th1 in which customers’ private account details were exposed.

Image of woman's left hand holding mobile phone with Spotify logo on screen
Photo by cottonbro on Pexels.com

Now, we may wonder why a hacker would be interested in Spotify accounts. Sadly, it’s not because they want to steal music inspiration from us. The details of targeted private accounts include customer display names, passwords, genders and D.O.B.’s which were leaked to various Spotify business partners. Speaking of business partners, we must also note that a Spotify breach does not solely expose Spotify users but may also put customers on connected devices or platforms at risk. The interconnectedness of our information sharing means that a problem for Spotify could be a problem for us all. This information is harvested by malicious actors to perform credential stuffing attacks, in which stolen passwords are used to uncover more stolen passwords for other sites and applications.

Meterian web scanner scan of www.Spotify.com, showing a security score of 0, a stability score of 99, and a licensing score of 72

Moreover, this would not be the last experience Spotify had of data breaches in 2020. A week later, a cyber criminal under the guise ‘Daniel’ infiltrated celebrity Spotify accounts including Dua Lipa and Lana Del Rey2. Although in this case it was not customers PII that was exposed, it still casts a shadow on Spotify’s claim of prioritising “protecting privacy and maintaining user’s trust” as outlined in an official statement released on the 9th December 20203.

Screenshot of twitter post of Lana Del Rey's twitter account hacked

Enter now: Meterian web scanner, which we’ve used to perform a quick surface scan of http://www.spotify.com to identify what security, stability and licensing risks of open source components are within the website’s codebase. Here we can see that Spotify currently has a security score of 0 out of 100, with 1 known vulnerable component – jquery 2.1.3 which has at least one high and several medium threats as confirmed by NVD4. Although we do not know for sure what the unlocked route of entry was in Spotify’s case, this open source entry may well have been it. Subsequently, there is nothing stopping cyber criminals from using this chink in the armour to perpetrate similar breaches in the future. 

Although the vulnerability was discovered on November 12th, Spotify disclosed that it was present within the system from as far back as April. This means that more than 320 million user’s personal data was at risk for at least 7 months prior. Having carried out our own analysis in a matter of minutes, we immediately notice that the vulnerable component in use is actually more than three years out of date! We hope their web and mobile apps get greater scrutiny with regards to the maintenance of their open source dependencies. At Meterian we have developed a security platform that automatically identifies known vulnerabilities in software applications’ open source supply chain. To give our customers the best chance of resolving such issues, the platform can be easily integrated in software development teams’ DevOps process. The continuous nature of DevSecOps empowers development teams to be the first line of defence as they code applications.

Open source components have become fundamental components of applications that are relied upon for basic functionality and security. Since over 90% of applications consist of open source components nowadays, securing this part of a business’ IT and software has become an area that requires greater scrutiny in quality and maintenance.

Meterian helps ensure software applications’ open source supply chain is free from any known vulnerabilities that could compromise the application’s security and stability. Is it worth risking to damage the firm’s reputation and competitive edge in the market?

Curious to see what we can automatically report on your software applications? Detect known vulnerabilities in your open source software supply chain before your own applications become an Achilles heel. Get in touch and see how Meterian can make your company’s application security defence more robust. 

1 Whittaker, Zack. “Spotify resets passwords after a security bug exposed users’ private account information.” Tech Crunch, 10 Dec 2020, https:// techcrunch.com/2020/12/10/spotify-resets-user-passwords-after-a-bug-exposed-private-account-information/

2 “Dua Lipa and other Spotify artists’ pages hacked by Taylor Swift ‘fan’”. BBC News, 2 Dec 2020, https:// bbc.co.uk/news/technology-55158317.

3 “Spotify Breach Notice Letter.” Spotify, 9 Dec 2020, https:// beta.documentcloud.org/documents/20422370-spotify-breach-notice-letter-californiadocx

4 U.S. Department of Commerce. “National Vulnerability Database.” https:// nvd.nist.gov/vuln/search/results?adv_search=true&cpe_version=cpe%3A%2Fa%3Ajquery%3Ajquery%3A2.1.3

Spotify vs Hacker, Round 2: Room for Improvement

Update to terms and privacy policy

viviandufourLeave a comment

We have updated our terms and conditions and privacy policy as our business grows to serve more customers across the software industry in financial, cybersecurity, e-commerce, health, IT and telecommunications sectors.  We look forward to welcoming more customers who want to secure their open source software supply chain as part of secure app development. Software developers, security officers, quality assurance and legal compliance professionals can benefit from easy to read reports to streamline their decision making processes.

Get in touch to book a demo! 

Update to terms and privacy policy

jQuery, Javascript vulnerability of the month

Marco Sciortino, , , , Leave a comment
Artwork by Marco Sciortino

Here we are! Guess what’s vulnerable again?
On April 10th 2020 it was made public that a vulnerability has been exploited in the most popular Javascript library ever implemented: jQuery 3.4.1.

Why is jQuery 3.4.1 vulnerable?

Vulnerability score: 5
Platform: Javascript
Components: jQuery, all versions before 3.5.0

When jQuery is invoked, it reads the HTML document and returns requested fragments of it.
Now, while reading the document it might find that the one or more requested fragments are not in the correct format, so it tries to translate them. Although most of the times the translation is correctly performed, it’s been demonstrated that in particular cases the conversion (or parsing) could lead to an XSS cross-site scripting vulnerability.

An XSS cross-site scripting is a type of code vulnerability that allows attackers to insert malicious code into the web pages viewed by other users. It might be exploited to steal information such as access tokens or other sensitive information. This is what a criminal or Black Hat hacker would do.

This is what a criminal or Black Hat hacker would do. White Hat hackers, on the other hand, would behave ethically and use their software White Hat hackers, on the other hand, would behave ethically. Using their software engineering knowledge, White Hat hackers would show how to exploit a vulnerability: publish useful information about it to make sure both users and owners of the vulnerable library could take actions to prevent attacks.

What actions are required to safely update?

The first thing to know is that all the old versions of jQuery have some sort of vulnerability.  Up until April 10th, version 3.4.1 was the only safe version available.  Fortunately, the new minor release 3.5.0 has been published to fix the XSS security vulnerability.

As suggested in the jQuery release note, updating to this latest version might break your code as, to prevent the abuse of this vulnerability, the HTML element phrase is no longer converted.
Therefore, a code review might be in order.

There is a lot of time-consuming effort involved in staying on track with all the latest code vulnerabilities as they are discovered but, fortunately, Meterian can help you with that.

When added to the CI/CD pipeline of any application, Meterian will automatically detect such vulnerabilities, or even fix them for you, and it will help you avoid the risk of an attack before it becomes a problem.

Beat open source vulnerabilities with Meterian.

jQuery, Javascript vulnerability of the month

Love Your Developer: How to maintain & secure your open source components?

Victoria C., , , , 1 Comment

6min read

Happy Valentine’s Day! Meterian is feeling the love, so we want to share it by telling you the best way your business can love their developers! In this article we highlight the benefits and costs of using open-source software.  We’re also going the extra mile to give you tips on how to secure and maintain these components without slowing down your developers – the guardians of your business’ software that can propel you ahead of competitors.  

Here’s a little history lesson for you to begin with! Back in the 1940s-70s, software innovated at a slow pace. It wasn’t even regarded as a valuable asset in the working environment. The 1980s came and we see how software copyright was introduced, commencing a period where there was a boom in software innovation and a burst in software companies.  As the decades went on, people started to realise the value of open source software.

In 2000, the use of open source projects as well as components, began to grow significantly. Market research has predicted the global market size to grow from USD 11.40 billion in 2017 to USD 32.95 billion by 2022. Open source software has lowered development costs and accelerated innovation by reducing time to market. Now we see that companies who innovate early are 67% more likely to outperform.

Benefits of open source software 

Sometimes taking advantage of free resources is better. For example, in 2010 the use of open source was so common, it became a table stake. All companies were using it, otherwise they would fall at a disadvantage to their competitors. Open source solutions speed up software/hardware solutions, save money, provide flexibility and help companies stay on top of technological developments. This is supported by a survey which found 53% of companies have an open source program or plan to establish one in the near future. 

Developers are able to become creative and help solve problems in the software space when using open source solutions. It is the consumer and producer relationship that makes open source software thrive. As a result, there is more software availability for all users without having to reinvent the wheel. This in turn helps organizations. Recent research from Harvard Business School has shown that open source contributing companies capture up to 100% more productive value from open source than companies that do not contribute back. It creates a snowball effect: the more companies use it, the more the community is able to survey, criticize and praise it. Therefore, this strengthens the quality of the software used, including its security, usability and stability.

Open source software also comes with management benefits. Organizations tend to struggle when managing huge volumes of structured and unstructured data. This is where open source solutions can help! It helps to simplify business processes, as well as saving resources for things which are not needed for the success of a business. Essentially, it provides more flexibility for the company.

Taking a look at customer value is important. Due to the flexibility of open source software solutions, companies are able to customize to suit the needs of their particular customers. For example when you integrate two pieces of software. This requires less time than if the company were to write the integration software from scratch themselves. Therefore, it benefits both the company and their customers as well. Customers might even be willing to pay more for better solutions if they see this software is meeting their needs so efficiently and rapidly. It is all about viewing open source software as a resource and a powerful motivator.  

Costs 

When it comes to the law, open source solutions can sometimes be restricted to certain countries. For example, GitHub made headlines when it made it difficult for developers in Cuba, Iran, North Korea and Syria to access private repository services. There have been changes for open source licences in response to these types of situations, as it should be allowed to continue to expand and not interfere with international rules on software access. So companies should always know what licences are tied to the software they are using to avoid an IP breach. Read our past blog post on how the wrong licence can harm your business, if you haven’t already!

Moreover, open source components are attractive to cyber attackers. Firstly, open source vulnerabilities within components are discovered daily. Secondly, traditional testing tools and methods are ineffective in identification and therefore few companies understand the components being used in their applications. This lack of awareness leaves organizations increasingly exposed to an attack. For example Hollywood Presbyterian Hospital in California suffered a ransomware attack due to an outdated JBoss server software. The attacker uploaded malware to the out-of-date server without any interaction with a victim. This resulted in delayed patient care and the hospital had to pay $17,000 to recover access to files and the network.

A further cost or strain is the need to constantly maintain, test and secure these components. For example, in 2018 Sonatype released its fourth annual State of the Software Supply Chain Report and showed how software developers had downloaded more than 300 billion open source components in the past 12 months, 1 in 8 of those components having contained known security vulnerabilities.

Not catching these security bugs early on in the development process can lead to very costly and damaging outcomes.

How to maintain and secure open source components?

Firstly, you can start by making an inventory of all your open source components used when developing software. This inventory must include all the components, versions in use and the download locations for each project. Software bill of materials (SBoM) would be this inventory.

There is also a need to map out any known security vulnerabilities. The National Vulnerability Database (NVD) is a great place to provide information on publicly disclosed vulnerabilities in open source software. However, make sure you do not use this as your sole source for vulnerability information, as sometimes not all vulnerabilities are reported and the format of NVD records make it difficult to see which versions have been affected.   Meterian uses several sources in addition to the NVD.

Open source solutions are a brilliant resource. But to maintain its benefits there needs to be an effort to secure the open source components to lower the risk of them being vulnerable to cyber attacks. For example, a study conducted by Kula et al. on migrations of 4600 GitHub projects showed that 81.5% of them do not update their direct library dependencies, sometimes even in cases when they have been affected by publicly known vulnerabilities. This emphasizes the lack of awareness about security vulnerabilities within open source software. For this reason, to secure your open source components there is an urgency to upgrade software and keep on top of the known vulnerabilities.

https://www.pexels.com/photo/close-up-photography-of-yellow-green-red-and-brown-plastic-cones-on-white-lined-surface-163064/

Security is a community effort. There is a testing process for each project that is open to everyone. Developers using open source software are able to judge. This community of users are constantly evaluating and testing the security of certain components. Following this, there will be feedback on issues that have been found. For this reason, building open source software is safer than proprietary software because more people can test and contribute to its security. At the same time, there must be care about the code contributions accepted. A governance process and reviews in regards to any open source contribution should be made.

Constant vigilance is key. More than 3,600 new open source vulnerabilities are discovered every year and a significant amount appear daily.  Developers need to make sure their use of open source software is secure. Asking questions such as, is the code I am using good? Does it have any bugs? Due to vulnerabilities being identified on a daily basis–some have more high risk than others–there needs to be a practice within organizations to monitor or test each time the software changes. 

Meterian helps businesses get the most out of their software investments

Open source software has been changing how our world works, giving us a sustainable ecosystem that can work for everyone as long as it is looked after.

Meterian can automatically inventory your open source components and analyse them to check if they are up-to-date or have any publicly disclosed security and licence risks. Get started on building a proactive defence for your customer data and software IP.  Love your developers and let them innovate freely while using Meterian to secure your open source components. We can block insecure code before it goes live.  It will save you and your developers time and money, allowing your business to be less vulnerable to cyber attacks.  

Check if there are any open source security holes in your company’s website that puts your business at risk of a data or IP breach before it’s too late.

Try our free webscanner today.

Love Your Developer: How to maintain & secure your open source components?