Three days after Uber’s epically bad cyber incident, I saw a LinkedIn post that featured their many new job openings in security. Like others that picked up on it, I found this funny, but not necessarily in a “haha” way; it was more like schadenfreude. It’s not that I was happy about how the attack would affect Uber’s users, but it was more about watching yet another company suffer the consequences of failing to invest in proper security measures before something bad happened.
Investing in security only after an attack is a pattern common among both small and large companies alike. I’ve personally worked in three different security fields–national, data, and software supply chain–and have noticed one constant that permeates all three: the most difficult part of working in security is making people care about security before an embarrassing cyber incident occurs.
Why does cyber security get left on the back burner?
To start, it represents a common aspect of many parts of our lives. We have limited time and money, so we prioritize things that we feel are the most important. Sometimes we have the foresight and ability to prioritize things that will be important in the future. Still, we often prioritize things right in front of us at any given moment.
It’s bad enough when this happens personally, but what happens when a company approaches the security of its software supply chain with this mindset? Uber's reaction is one of many possible results.
Sadly, Uber is not the first organization, nor will it be the last. It goes all the way to the top, illustrated by the United States government reacting to the huge Solarwinds hack by appointing new cybersecurity officials.
Log4j is another example. Despite being one of the worst bugs in internet history, it’s still being exploited. What’s perhaps most surprising is that many security vendors have been citing stats that downplay risk in order to amplify their services. This is happening even as groups in China, Iran, North Korea, and Turkey continue to exploit Log4j in unpatched organizations.
How do you convince organizations to better prepare for cyber incidents?
CISOs and security teams are almost always passionate about this subject; the challenge is convincing their peers. Financial, legal, and executive teams can be persuaded once they consider how much an embarrassing incident would damage the company’s reputation. Not to mention the associated legal and financial risks.
The unique challenge for software companies starts somewhere you might not expect–with the developers.
You might think that security is always top-of-mind for software developers, but most of the time, their biggest concern is focusing on coding and minimizing distractions. They appreciate the tools that help them, like the way coffee helps them focus on coding. They don’t appreciate the distraction of technical debt incurred by using risky open source packages they’ve selected. As a result, instead of seeing them as useful, many developers believe security products only serve to distract their next sprint–clearly, a detriment surpassed only by an empty coffee pot.
How the Nexus Platform provides indispensable value to developers and organizations
As Sonatype discovered and presented in our 8th Annual State of the Software Supply Chain, “The higher the level of [software supply chain management] maturity, the higher the reported employee satisfaction, and vice versa.”
Software developers are more satisfied when they have tools that enhance their ability to innovate and write software. Using the Nexus platform helps an organization protect itself from known and unknown security vulnerabilities, and it helps the software developer focus on what satisfies them.
The following examples highlight ways the Nexus platform does this for developers:
- Policy driven scans during the development process highlight issues that will eventually block their production build. This gives the developer an opportunity to make better open source dependency choices early in the development cycle, minimizing distraction later.
- Seeing vulnerable component information and remediation recommendations early in the development process allows for faster fixing and cuts down on time spent researching risky dependencies, leading to faster innovation.
- Let’s be real: applications written in some languages pull in hundreds or even thousands of transitive dependencies that the developer may not be aware of–including those that put their own application at risk. Nexus Lifecycle’s uniquely accurate method of finding all transitive dependencies during the build process prevents technical debt from finding vulnerabilities later (and prevents embarrassing situations for companies that don’t even know they’re using a component when it gets exploited, like Log4j).
- Another fact highlighted in our latest State of the Software Supply Chain Report is that open source software is under attack, and there is no way software developers in an organization will catch all of the threats.
- Nexus Firewall’s Release Integrity, and specifically, suspicious and malicious protection, keeps developers from making costly mistakes. It prevents known and potentially risky dependencies from even making it into the development environment, like those seen in typosquatting attacks.
- Nexus Firewall’s Policy Compliant Component Selection lets npm developers focus on coding by automatically choosing the most recent version of a component that’s compliant with the organization’s IQ security and license policies.
To learn more about how the Nexus Platform empowers developers and fuels innovation, schedule a demo with a member of our team.