Great news for all you mobile developers out there! Meterian, a leading Software Composition Analysis (SCA) platform, has just rolled out support for Dart, the programming language that’s become super popular for building Flutter apps. If you’re crafting mobile apps with Flutter, this update is specially tailored for you. Let’s dive into what this means and why it’s a game changer for Flutter developers.
Why Dart and Flutter are a big Deal
Developed by Google, Dart is all about building smooth and stunning mobile and web applications, and it’s the powerhouse behind Flutter—Google’s UI toolkit for crafting beautiful, natively compiled applications from a single codebase. Flutter’s ability to deliver apps that feel great on both Android and iOS has made it a hot favorite. With Dart now getting the spotlight it deserves, security and efficiency in app development are set to reach new heights.
Meterian embraces Dart
With Dart on its radar, Meterian is making sure that your development toolkit is not just powerful but also secure. This inclusion means Meterian can now safeguard your Flutter projects right from the get-go, catching potential security slip-ups before they become real headaches.
Meterian’s leap to include Dart is more than just an update—it’s setting a new standard for mobile app security. By embracing the needs of the Flutter community, Meterian is not only beefing up the security of apps but is also paving the way for projects that scale smoothly and stay robust under pressure.
What’s in it for Flutter developers?
We believe Flutter will eventually get a dominant position in the mobile development scene, so it’s essential to have tools that ensure that your applications are rock-solid safe. Meterian’s support for Dart brings you a suite of benefits:
Boosted Security: Spot vulnerabilities early in the development cycle with Meterian’s SCA tools, keeping your apps safe from security threats.
Stay on the Right Side of Compliance: Keep up with the latest security standards easily, ensuring your app complies with legal and regulatory requirements.
Seamless Development Flow: Meterian fits right into your existing workflows, helping you patch up security issues without slowing you down.
Scale with Confidence: As your app grows, Meterian grows with it, making sure that even the most complex projects stay manageable and secure.
With Dart in Meterian’s toolkit, it’s an exciting time to be building apps with Flutter. This move shows Meterian’s commitment to supporting the latest and greatest in app development, making it easier for you to build apps that aren’t just awesome but are also secure and compliant. To learn more about Meterian’s support for Dart/Flutter and how it can help improve the security of your projects, visit Meterian’s website at www.meterian.io.
In the digital age, healthcare companies are guardians of vast amounts of sensitive user data, ranging from personal health records to financial information. With this responsibility comes the challenge of ensuring data integrity and security against the growing threats of cyberattacks and data breaches. Meterian, a leader in application security, is at the forefront of providing solutions that safeguard this critical data.
Healthcare providers harnessing open-source software face unique security risks that require vigilant management and protection strategies. Meterian’s innovative tools actively scan and identify vulnerabilities within applications, ensuring that all components are up to date and secure against potential threats. By leveraging Meterian’s capabilities, healthcare companies can not only protect their patient data but also enhance their overall cybersecurity posture.
Protecting patient records.
In collaboration with Emis Group, a well-established brand in healthcare technology, Meterian has demonstrated its value in real-world applications. Emis has utilised Meterian’s solutions to bolster their applications’ defences, thereby protecting millions of patient records. While our partnership with Emis illustrates Meterian’s capability to handle the complex cybersecurity needs of large enterprises, it’s important to recognise that our solutions are equally effective and accessible for SMEs and startups. Meterian understands the unique challenges faced by smaller organisations, including tighter budgets and limited resources, as our platform is designed to be flexible and scalable.
For healthcare organisations, the fear of missing out on the highest level of security should be a significant concern. Meterian provides an essential layer of security that automates and streamlines the detection and management of vulnerabilities—tasks that would otherwise consume valuable development resources. As legislation evolves and compliance becomes even more stringent, Meterian’s tools help healthcare companies stay ahead, ensuring they meet all regulatory requirements while securing user data against emerging threats.
A successful case study.
To see first – hand how Meterian is enhancing cybersecurity in the healthcare industry, we invite you to explore our success story with Emis Group. This case study provides a detailed look at how Emis leveraged Meterian’s cutting-edge solutions to fortify their application security, ensuring compliance with stringent regulations and protecting sensitive patient data.
The UK government’s flagship cyber security event, CyberUK 2024. is just around the corner! Hosted by the National Cyber Security Centre (NCSC), this annual gathering brings together over 2,000 cyber security leaders and professionals for networking, knowledge exchange, and collaboration.
We will be exhibiting at CyberUK 2024. Loved by SMEs and CNI, our secure-by-design agile approach to software development delights developers and compliance teams. Come and learn how Meterian protects the Open Source Software Supply Chain.
Visit us Stand IZ3 at the Birmingham ICC, May 13-15th.
Since its inception in 2005, the National Vulnerability Database (NVD) has been a vital resource for security professionals, providing details about common vulnerabilities and exposures (CVEs) discovered by researchers worldwide. However, in recent months, the NVD has faced significant challenges, resulting in delays and incomplete data. In this blog post, we explore the current state of the NVD and its implications for enterprise security.
The Mysterious Freeze
In February, the NVD underwent an unexpected transformation. A cryptic announcement appeared on its website, stating that users would “temporarily see delays in [our] analysis efforts” while the National Institute of Standards and Technology (NIST) implemented improved tools and methods. Unfortunately, no further explanation accompanied this message. The freeze affected the timely documentation of CVEs, leaving security managers in a bind.
The CVE Model and Missing Details
The NVD relies on a network of 365 partners—both US-based and international—who contribute threat data. These partners include software vendors, bug bounty operators, and private research firms. Each participant adheres to a schema to ensure unique and accurate entries. However, since the beginning of the year, over 6,000 new CVEs have been posted, with nearly half lacking essential details in the NVD.
What’s Missing?
Metadata: The latest CVE entries lack critical metadata, such as information about affected software. Without this context, security managers struggle to assess the severity of vulnerabilities and prioritize patching efforts.
CVSS Scores: The Common Vulnerability Scoring System (CVSS) scores, which indicate vulnerability severity, are absent for many CVEs.
Product Information: Enterprises rely on NVD data to identify which applications and operating systems are at risk. Unfortunately, the missing details hinder this crucial aspect.
The status of things (April 2024)
In this recent update from the NVD team they discuss the importance of the National Vulnerability Database (NVD) and the challenges it faces. The NVD is a repository of information on software and hardware flaws that can compromise computer security. There is a growing backlog of vulnerabilities submitted to the NVD, and NIST is working to address this challenge. NIST is committed to its continued support and management of the NVD, but at this time it seems to be lagging behind.
How Meterian can help
Enter Meterian, a comprehensive application security solution that offers unique advantages over traditional databases. Meterian has an extremely robust security database that implements:
Automated Daily Updates: Unlike the NVD, which has experienced recent delays, Meterian’s security database is updated at least every 4 hours. This automated process ensures that you receive the most current threat intelligence promptly.
Diverse Data Sources: Meterian aggregates data from more than 15 unique sources, including both public and private feeds. These sources contribute to a comprehensive repository of vulnerability information, covering a wide range of software components. This is also enriched by Meterian AI and internally curated databases.
Monitoring 350K Vulnerabilities: At present, Meterian actively monitors around 350,000 vulnerabilities across various ecosystems, from Perl to Rust. If you’re building applications and dealing with open-source libraries or frameworks, Meterian has you covered.
Conclusion
As the NVD grapples with its challenges, consider integrating Meterian into your security toolkit. Stay informed, stay proactive, and safeguard your digital assets effectively. Alternatively, you can simply start receiving timely notification through our alerting system: please check out our previous article that explains how to do just that!
The open-source software (OSS) ecosystem thrives on the principles of transparency and collaborative development. However, a recent critical vulnerability discovered in the core library, liblzma, has cast a shadow on this trust. The vulnerability, which was disguised as a bug fix, contained malicious code that could have potentially granted attackers access to users’ systems through SSH servers. This unsettling incident serves as a sobering reminder of the tangible risks inherent in relying on third-party software packages, even within the seemingly open and collaborative realm of OSS.
What happened?
liblzma, a critical library used for compression in many Linux distributions, was compromised by a backdoor hidden within its source code. This backdoor, attributed to a contributor named Jia T75, remained undetected for two years. During the build process, the backdoor would infect the system, specifically targeting x86_64 Linux systems. This vulnerability could have allowed attackers to compromise SSH servers, potentially granting them unauthorized access to a user’s system.
Why third-party packages are a risk
While OSS thrives on collaboration, it also introduces vulnerabilities. We rely on the good faith of developers contributing code. Malicious actors can exploit this trust by injecting backdoors or other harmful code into seemingly legitimate libraries like liblzma.
What can you Do?
To mitigate the risks associated with third-party software packages, it is imperative to stay vigilant and proactive. Patching software promptly by updating your system regularly ensures you have the latest security fixes in place. Furthermore, exercising caution when obtaining software updates and packages by exclusively utilizing official or trusted sources is of utmost importance. Thoroughly researching the maintainers of the software packages you rely upon can shed light on their track record of responsible updates and reputation within the community. Whenever feasible, exploring alternatives to widely used libraries can be a prudent strategy, as diversifying your software portfolio can reduce the potential impact of a single vulnerability. By adopting these measures, you can bolster the security posture of your systems and minimize the risks posed by third-party software dependencies.
How Meterian can help
The liblzma backdoor incident serves as a wake-up call, and it highlights the need for constant vigilance. By understanding the risks and taking preventative measures, we can build a more secure software ecosystem. Remember, security is an ongoing process, not a one-time fix .
Security solutions like Meterian can be powerful allies in mitigating the risks of third-party packages. Meterian’s notification system keeps you informed about the latest vulnerabilities impacting your software ecosystem, including critical flaws like the recently discovered liblzma backdoor. Through timely alerts and detailed reporting, Meterian ensures you stay on top of potential threats before they can be exploited]. Additionally, Meterian’s Software Composition Analysis (SCA) solution goes a step further by scanning your codebase for known vulnerabilities within dependencies like liblzma. By proactively identifying these risks, SCA allows you to take early action and prioritize patching vulnerable components, ultimately safeguarding your systems and data.
Don’t wait for the next major vulnerability to compromise your systems. Take control of your software security today. Try Meterian for free and experience the power of proactive vulnerability detection and management.
An important note!
The xz/liblzma packages are sometimes included in major Linux distributions, and much of the focus is now there, also because this vulnerability can be exploited to execute remote commands over SSH. However, please be aware that this vulnerability may affect also your application code, either because it may be linking directly liblzma in your C/C++ applications or because, via conan, you previously used the package xz_utils in one of the vulnerable versions (5.6.0, 5.6.1). Furthermore, other wrappers such as xz.ex (elixir), xz.net (dotnet), ruby-xz (ruby) and similar packages may indirectly pull the affected package.
Update – 15 April 2024
This is a novel situation, and there is still much uncertainty. We are aware of only a single known exploit path at this time, but there may be additional scenarios that have not yet been identified.
In detail, so far, it looks like the payload activates if the running program has the process name /usr/sbin/sshd, however, based on ongoing analysis, it may activate also in other scenarios too, unrelated to SSH. This matter is still investigated, you can keep an eye at this page to follow the active investigation.
Stop worrying about missing critical vulnerability alerts. As application security experts, we know the constant struggle to stay informed about the latest threats facing your open-source components. That’s why we’re excited to introduce Meterian’s vulnerability notification system, designed to provide timely, accurate, and actionable information so you can take immediate steps to protect your applications.
Unparalleled Insight into Open-Source Risks
Meterian boasts the largest OSINT vulnerability database on the market, meticulously tracking over 335,000 vulnerabilities daily across 20+ diverse sources. We go beyond mere quantity, offering almost 94,000 unique vulnerabilities spanning 16 programming languages, ensuring comprehensive coverage for your development stack. Every day,
Never Miss a Critical Update
Our system proactively identifies new open-source component vulnerabilities and critical updates, delivering comprehensive notifications straight to your inbox. Each notification contains all the essential details to address the issue effectively:
Precise component name and ecosystem
Affected version range
Detailed vulnerability description
CVE identifier (if available)
Associated CVSS and EPSS scores
List of unaffected versions
Links for further exploration
What’s a CVE?
A CVE is like the official scoreboard listing of a severe foul or broken piece of equipment (a security flaw) that the entire league (the tech world) agrees must be fixed. Meterian acts as your team’s Defensive Coordinator, constantly watching the game for any new fouls and sending a precise, instant notification only to the players (developers) who are currently using that faulty gear, telling them exactly how to swap it out for a legal one before the referee throws a flag (a breach).
We believe that staying informed about vulnerabilities requires a comprehensive view. That’s why our platform not only delivers daily updates but also offers a valuable 30-day history, for free. This historical perspective allows you to track the evolution of vulnerabilities: whether you’re a seasoned developer or an individual user, understanding the trends over the past month can empower you to make informed decisions and take proactive security measures. Visit our Meterian Vulnerabilities pages to explore this rich history and stay ahead of the curve.
Tailored Alerts for Subscribed Users
We understand that information overload can be counterproductive. That’s why we offer two distinct notification systems for subscribed users:
Sentinel that continuously monitors previously scanned projects
Allerta that provides alerts based on a user specific preferences
Our Sentinel Notification System is your ticket to continuous security monitoring. It offers timely alerts to development teams, even without active scans. Once a project is under Meterian’s purview, Sentinel automatically and routinely examines it for new vulnerabilities. This seamless process ensures ongoing security screening, eliminating the need for user intervention. With Sentinel, you can rest assured that your projects remain protected around the clock.
The Allerta Notification System is designed with flexibility in mind. It allows users to tailor security alerts based on their preferences. You can define your interests, specifying preferred ecosystems, and scoring thresholds, ensuring that you receive notifications that align with your specific needs. Whether you’re a developer focusing on a particular programming language or a security professional seeking a broader view, Allerta provides precise information tailored to your requirements. With Allerta, you gain the ability to customize your security alerts while staying well-informed about the vulnerabilities that matter most to you.
Empowering Developers and Security Teams
Developers can focus on specific languages, while security personnel maintain a global view. All notifications provide granular details, including the affected component and version, so everyone has the context needed to make informed decisions. Don’t wait for a breach to expose your vulnerabilities. Meterian’s notification system empowers you to take control of your application security.
Sign up for a free trial today and experience the power of proactive application security. See for yourself how Meterian can keep you ahead of the curve and your applications safe. And remember, you can always consult thedaily vulnerability report online, completely free: no subscriptions needed.
Take action now and protect your applications from the ever-evolving threat landscape!
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.
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.
The breaking news in December 2021 of the zero-day vulnerability in the Java logger Log4j 2, known as Log4Shell, sent shockwaves through organisations around the world. Over the last 20 years Log4j has been used globally in billions of software developments and applications for logging incidents. This meant that until the vulnerability could be mitigated, the doors were open to millions of organisations. Attackers could break into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage. The issue was also a major threat to corporate reputations, especially where trust and confidentiality was key, such as in the financial services sector.
In the early hours an alert notification about the Log4j critical vulnerability reached one major financial services organisation based in the UK, with Fortune 500 clients around the world. On hearing the news, the Director of DevOps and Engineering cross-checked other sources for corroboration, including social media, and contacted the organisation’s Lead Technical Security Officer. It was clear that, unchecked, this could be a major problem, but how big an issue would depend on how widely Log4j 2 was embedded into systems used and being developed throughout the corporation.
Often in the race to innovate and implement systems quickly, documentation may not be as comprehensively kept and updated as ideally required. In its absence, it can be difficult for an organisation to discover how widely Log4j is integrated within its application estate, let alone know if it has been previously patched.
The race was on against the malicious actors poised to automate exploitation of Log4J vulnerabilities, with major impacts for the corporation and potentially for millions of customers around the world.
Mobilising the IT & Security Workforce with Meterian
The organisation moved rapidly by using Meterian’s out-of-the-box reports to enable it to identify where Log4J vulnerabilities were to be found across its application estate, and hence the size of the potential problem. Only then could it be possible to build a remediation plan to mitigate the risks of all the Log4J vulnerabilities.
By 10am, the list of projects utilising the Meterian solution could be seen via the Meterian Dashboard and automated scanning initiated. Scanning the software bills of materials of the affected projects, an indication of the potential impact of Log4J was emerging which could give direction and scope on the follow-up actions. Other projects which had not yet begun to use Meterian as part of their regular processes, found that Meterian’s simplicity of use meant that they could also quickly scan their projects for vulnerabilities.
Working methodically and forensically with the organisation’s development teams across multiple locations, by 5pm it was possible to present to senior management a concise summary of the situation, showing areas of the business at risk; those projects which had already been remediated; and those still needing work. A comprehensive communication plan was then invoked to alert the business to remaining vulnerabilities.
The following Meterian tools were used:
Meterian Sentinel notification alerts: an always-on security messaging service which sends notification alerts, emails, or Slack IMs to account administrators about new public vulnerabilities found in open source components used by their projects.
Meterian Boost Open Source Security (BOSS) Scanner: which gives instant visibility to the application’s open source dependencies with automated discovery, risk scoring, continuous scanning, and actionable security insights.
Meterian Account Dashboard: insight reports show dependent components and related Critical/High/Medium/Low vulnerabilities within the remit of a particular account.
The Meterian toolset alerts key employees to security issues and vulnerabilities; the breadth of the issue for the organisation’s application estate; and the projects impacted. The CISO is then armed with all the information needed to mobilise an effective action plan and comprehensive remediation.
Visibility and Control of Vulnerable Components
Log4J created great upheaval in IT teams across the industry, but for this business unit at this global Financial Services organisation, Meterian tools rapidly delivered a complete view of projects that were susceptible to attack. In comparison, other business units were not able to gather such insights so quickly because there was no single comprehensive reference point which was easy to access and use.
Meterian enabled a speedy time to resolution: 2 hours to implement remediation on projects identified using Meterian as having the Log4J vulnerability.
Meterian freed up employee time from finding the vulnerabilities, enabling them to focus on isolating the application estate from risk and implementing remediations. The Log4J threat demonstrated that critical incident prevention is possible with a more automated, secure-by-design approach. Additional or external staff were not required as existing employees could use smart tools on their application estate, and on a more regular basis to save time and remove headaches.
Through using Meterian the organisation benefits from:
Prompt alerts and early warnings of vulnerabilities in the open source software supply chain
Enhanced protection against threats
Increased confidence in people and tools working together to protect from organisational risk
Decreased stress that vulnerabilities will cause major damage and reputational harm
Reduction in “known unknown” risks and number of security fires
Cultivating Cyber Resilience Consistently and Responsively
The organisation is using the effective response enabled by Meterian as a case study to demonstrate that regulatory and compliance requirements can be met with easy-to-use continuous scanning tools that provide immediate visibility and quicken the development of secure code.
The proven partnership with Meterian will extend and facilitate their further innovation in automation, analytics and cyberresilience, through even more responsive and secure development.
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.
Red alert! All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered vulnerabilities “Spring4Shell” since its announcement, between 29th and 30th March, 2022, affecting various Spring components.
Vulnerability Score: 9.5 (CVSS:3.0 / AV: N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H) Platform: Java Components: org.springframework:spring-beans Affected versions: all versions before 5.2.20, all versions before 5.3.18 Fixed in version: 5.2.20, 5.3.18
Please note that this affects also the spring-framework package and the spring-boot package, that both use the offending libraries. New versions of such packages have been made available. You can upgrade spring-framework to version 5.2.20 or 5.3.18, and you can upgradespring-boot to version 2.5.12 or 2.6.6 (note that spring-boot itself includes spring-framework, no other upgrades necessary).
Which systems does these affect?
CVE-2022-22963 affects any project built using a vulnerable version of Spring Cloud, a framework that provides tools for developers to quickly build some of the common patterns in distributed systems. The “functions” part is a subsystem used to implement serverless functions like AWS lambda or Google Cloud Functions: if you are using such subsystem you are potentially affected.
CVE-2022-22965 affects any project built using a vulnerable version of Spring Framework, Spring Boot or the library spring-beans. A successful attack, however, can only be conducted undere these conditions:
JDK 9 or higher is used as the runtime environment
Apache Tomcat is used as the Servlet container
The application is packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
There is a dependency with spring-webmvc or spring-webflux, or an endpoint is used with DataBinder enabled
Please note however that analysis are undergoing and the nature of the vulnerability is quite general: we suggest you keep monitoring this page for further updates.
Why do these threats demand an urgent patch?
Both vulnerabilities allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers. It’s a simple exploit, as it requires only to send a crafted HTTP header in a request in order to execute code on the remote host. These vulnerabilities are actively exploited in the wild.
How can I check if my system is affected?
If you maintain any software using Java libraries, check if you are using any Spring Cloud Function library. The Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries. If it is using the offending package, 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:
If you see any response lines, check the version: if it’s below 5.3.18 (as in the above example) or, if using 5.2.x, below 5.2.20, you may be affected.
My system has the vulnerable spring cloud function library — how can I mitigate the risk?
There are now patched versions of the affected components that resolve the issues, they are available via the standard Maven repositories. Upgrade the offending packages using the patched versions, as described in this article.
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.
Please be aware that there are multiple packages rooted in "spring-cloud-function": you will need to upgrade all of them, in particular "spring-cloud-function-context" which is also directly affected.
Please be aware that you may need / may be better to upgrade the parent pom of the project using an unaffected version of spring boot / spring framework (see at the start of the article).
What can I do to proactively protect from such vulnerabilities?
We always suggest you regularly scan your software code bases.
To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.
Are Meterian applications affected by the spring vulnerability?
We have verified our applications and none are using the offending packages in a vulnerable configuration. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components. Given the nature of this vulnerability we will be running a specific monitoring for the following days, while more details are unfolded in regards to those vulnerabilities.
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.
