A year after the SolarWinds Sunburst hack we have Log4Shell. Both of these incidents have affected a multitude of organizations, often in very serious ways. There are many lessons to learn from both incidents but this post focuses on three which concern how organizations consume open source software.
Be more Unix
When developing libraries or frameworks and considering what features to add, be more like Unix than Windows. In other words: do one thing and do it well.
Log4J, the highly popular logging library, provides a lot of extra bells and whistles and it is in these where the recent CVEs have occurred. I am quite sure, though, that many other popular libraries in all modern languages (Java, Ruby, Node, Python, PHP etc. etc.) also contain plenty of extra bells and whistles. My, perhaps obvious, point is that the more features the more chance of introducing a vulnerability. So, when considering a new feature, be very cautious about adding it.
Equally, when using a feature-rich library, adopt a principle of ‘least enabled’, i.e. only switch on features that you know are required and will be used, not those which you think might come in useful one day. Frameworks like Spring Boot, ExpressJS, Django etc. are very feature-rich and often many of these are enabled by default. Take the time to understand which of these features you really need.
Externalize cross-cutting concerns
As part of application design and development, consider the cross-cutting concerns that will need to be addressed in your application, e.g. logging, metrics, encrypted communications, service discovery, caching and so on. Do these concerns really need to be handled within the application (with all the associated libraries, code and configuration) or could all/much be externalized?
A good example is logging: many logging frameworks provide the ability to send logs to a variety of locations: stdout, files, alerting services, URIs etc., but should your application be responsible for this? Arguably a better approach is to ensure your application sends its logs to stdout and use a log collector service (like Fluentd or Logstash) to actually route the logs to all necessary end locations.
Benefits of this approach include: less code and configuration in your application components (and therefore testing), development teams are not required to understand the logging requirements of other teams (operations, security etc.) and alterations to the logging configuration won’t require the configuration of multiple components to be changed and rolled out. Clearly this approach can be applied to other cross-cutting concerns, with the same benefits being achievable.
Inventory your open source
There are many popular OSS libraries and frameworks in use in millions of applications globally and I think it is almost inevitable that critical vulnerabilities will be found in at least some of these. Thus, it is essential that any organization that uses open source components can answer these questions when new CVEs are discovered:
- Do we use the vulnerable component?
- In what applications do we use it?
- Will the vulnerability affect us and what is the impact and risk level?
The quicker the answers are provided, the sooner a mitigation plan can be developed and enacted. Providing these answers quickly, though, requires a readily available inventory of all OSS components in use in the organization. This is not an easy undertaking but I strongly recommend that maintaining such an inventory is included in every organization's strategy for improving the security of their software supply chains.
Venafi experts from Jetstack are already working with a number of organizations to help them inventory and manage their use of open source. If you would like to know more on how to address these particular issues you can set up a discussion by contacting us here.
Cover photo by Markus Spiske on Unsplash