What I wish I knew about security when I started programming

Software developers are creative problem solvers. Their job is to build functioning applications, and they deal with rapid changes—in technologies, tools, and programming languages—as the landscape evolves and the development velocity accelerates. A key part of the development process is ensuring that the products delivered meet user needs and the goals of the business. And while they may not always be thinking about security, developers are, in fact, on the front lines of building secure applications.

Some developers don’t think about application security because it seems like something that happens outside their control and their reach. Some don’t have adequate security training and are not aware of what’s required to build a truly secure application. And in fact, security threats are always evolving, and information from a training session can quickly become out-of-date. Or it might be that because the organization already has some level of security (like a firewall, web application firewall, or endpoint protection), they think they don’t have to worry about building security into their applications.

Unfortunately, for many organizations, this lack of security awareness means that applications might be built with vulnerabilities that make it easier for bad actors to breach the system and gain access to sensitive data. Security testing is a critical step in every development process, but when issues are not identified until after the application is in production or has been released, security teams have a harder job. They have to work with the developers to repair the code, which can cause significant delays.

Developers want to build flawless applications, but no matter how excellent the features and functionality may be, it is not possible for any software application to be perfectly secure. The goal, for both developers and the security team, is to make it harder and less profitable for someone to break in.

Shifting left

With today’s rapid development timelines—hours and days instead of weeks and months—it is no longer an option for anyone along the software development life cycle (SDLC) to not be considering security. DevOps teams need to build in processes to secure the applications at the earliest stages of the SDLC and have enough competency in application security to do some basic tasks. They also should be able to recognize when a security issue requires specific domain knowledge, so they can call in the relevant expertise to address the issue.

That is the shift to the left: finding and fixing bugs early in the development process instead of waiting until postrelease testing. When you consider that the average cost of a breach in 2022 is US$ 4.35 million, and that 83% of organizations have experienced more than one breach, it’s clear that fixing vulnerabilities and bugs early in the development cycle is the most cost-effective, and potentially reputation saving, way to go.

To make that shift, organizations need to build security into the entire SDLC. There are a variety of automated application security tools that support developers and don’t interrupt this development timeline. These tools enable developers to prioritize and fix vulnerabilities at the point they are identified, when they are still working on the code and it’s much easier to make the change.

Developers can also benefit from understanding the various security technologies and processes, and how they relate to their organization. For example

• Software composition analysis (SCA) identifies open source software used in a codebase to evaluate security, license compliance, and code quality. It can be used before ever deploying an application and pinpoint the source of known vulnerabilities.
• Static application security testing (SAST) analyzes source code during the build process or even directly from the developer’s integrated development environment (IDE), and can identify lines of vulnerable code. Like SCA, SAST can be used before the application is deployed. After several cycles of fixing issues identified during SCA and SAST, the application can be deployed for IAST and DAST testing.
• Interactive application security testing (IAST) generally takes place during the test/QA stage of the SDLC and catches problems as soon as code is changed and recompiled. It helps identify vulnerabilities in real time.
• Dynamic application security testing (DAST) examines an application in the production system or in the text/QA system. It identifies vulnerabilities at runtime, but doesn’t identify the lines of vulnerable code.
• Penetration testing (pen testing) is an authorized simulation of a variety of types of attacks when the software is ready for production and deployment. It can help organizations identify weaknesses in the system.