By Eric Baize, vice president, product & application security at Dell Technologies
Back in the day, software development was a dark art. High priests, versed in the magical language of Fortran or Pascal, would cast digital spells that no one else in the business could understand. These days, things have changed. Modern tools and techniques have democratized software development. Now, anyone with an IDE and a boot camp diploma in full-stack development can do it.
As such, an army of programmers with a shallow security education have joined veteran, college-educated programmers–neither of whom have received thorough security training.
Granted, they’re taught how to avoid bugs in software, but they’re not taught how to avoid software vulnerabilities (bugs with security consequences). The void is as non-sensical as asking engineers–who are not trained in fire safety–to plan, design and inspect an apartment block.
These statistics tell the story. In 1999, Mitre Corp.’s CVE database logged just 894 software vulnerabilities. Last year, that number jumped to 20,141. Part of that is, doubtless, because we’ve developed more software and we’re better at spotting its flaws, but it’s also down to a fundamental problem with our development process.
To change that, we need to make our software development more secure.
Time for a change
The current approach to software security isn’t working. Modern developers have been taught to focus on features and performance. They test for vulnerabilities at the end of the development cycle, which is too late. It’s tantamount to trying to change the design of a car when road-testing it.
That’s a problem for several reasons. First, testing close to the deadline leaves teams time-constrained. In the rush to ship, it’s easy for vulnerabilities to slip through and become discoverable by others (who might then weaponize it to attack others)–forcing companies to issue emergency patches. Anyone who does not immediately apply the patch would then be exposed as vulnerable.
Placing the onus on users to patch software after the fact is becoming less sustainable as the vulnerabilities mount. More patching increases their management overhead and total cost of ownership. Moreover, some customers in highly regulated environments or with limited resources might not be able to patch quickly enough.
This last-minute security approach also leaves fundamental design flaws unfixed. Often, the only way to fix these flaws is to unpick the software’s core architecture. With no time to handle that, they end up in expensive and risky technical debt.
Software security must ‘shift left’
The answer to this problem lies in making security a first-class citizen rather than a back-row passenger in cattle class. This encompasses examining software through the attackers’ lens earlier in the software development process. From design to deployment and beyond, developers must think like hackers and devise innovative ways to attack their own products.
Building an SDL
In short, we need a secure development lifecycle. This considers security at all steps in the development process:
- Requirements gathering: Developers used to drawing up user wish lists must expand their thinking to include the software’s security objectives.
- Software design: When creating the product architecture, threat modeling enables developers to understand the potential risks to their software.
- Coding: Developers must follow coding best practices. There are plenty available, including guidance on secure web applications from the Open Web Application Security Project (OWASP). Static analysis tools can also comb through source code for insecurities.
- Testing: Developing security-focused tests will help to identify vulnerabilities in software. That means thinking like a hacker when you create your test cases (try inserting some SQL injection commands in your input validation tests). Developers can also use specialist testing tools like fuzzers that spot difficult-to-detect flaws. Consider moving to a test-driven development practice where you write the tests first and the code afterward. Development teams can also follow best practices by testing code before each commit, remembering that attackers find vulnerabilities by testing software outside of normal boundaries.
- Release: Developers can create KPIs to hit before they are allowed to release a product. These could include bugs identified during static analysis, along with test coverage metrics.
- Maintenance: Developers must design software to be ready to be updated when, not if, the proverbial vulnerability will have to be addressed. It includes making sure the software is easy to update (no one wants a car recall for a software update) and keeping an inventory of third-party components that must be kept up to date. This is where automation can help. DevOps isn’t a necessary discipline but does offer an excellent platform for automated testing and gated releases to help enforce SDL principles at scale.
SDL examples
While this might all sound daunting, thankfully we already have guidance on how to create an SDL. Microsoft was among the first to implement one, with its Security Development Life cycle publicly launched in 2008. The National Institute of Standards and Technology (NIST) has its Secure Software Development Framework (SSDF), while OWASP offers the Comprehensive, Lightweight Application Security Process (CLASP). SAFECode, a nonprofit organization that promotes secure software development, offers its Fundamental Practices for Secure Software Development guide and collaborated with NIST on the SSDF.
Now or never
Gauging the trustworthiness of the software deployed in your organization is critical. Software developed ten years ago cannot be trusted at the same level as today’s software. Understanding how and when the software was developed should inform how you use it and whether additional measures, like network segmentation, application allowlisting (a security measure that only allows preapproved applications or processes to run) and sandboxing (where you run, observe and analyze code in a safe, isolated environment) are needed to add layers of protection.
As the security stakes rise, the SDL concept becomes more important too. We cannot build castles on sand. Robust systems need robust foundations. An SDL should be a priority for every software development team–manifest in the training they provide; their security posture (so they’re always ready to address vulnerabilities) and their ability to think like an attacker from day one.
With the cybersecurity talent shortage being what it is, no other option works. Outsourcing software security to security researchers and hackers as a primary means of addressing vulnerabilities is just too sloppy and dangerous. We need to make secure development the backbone of every software development team and the centerpiece of software engineering education.
Lead photo by ThisisEngineering RAEng on Unsplash
This article is the first in a four-part series on secure product development. Be sure to check out the rest of the articles in the series:
Catching bugs on the loose: vulnerability management for software developers
How to grow a secure software culture from the inside out
How to secure your software supply chain when using open-source technology