close search bar

Sorry, not available in this language yet

close language selection

What I wish I knew about security when I started programming

Allon Mureinik

Aug 26, 2022 / 4 min read

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.

What developers need to know

A developer’s job is to create features that achieve the goal of the application. Their mindset is focused on building a useful product. To be able to develop truly secure applications, there are several skills that developers need in addition to their engineering knowledge and focus on functionality. This includes basic security concepts and use cases for security technologies, and how those relate to their organization.

Developers need to understand how to prevent threats. But this can be challenging because developers think about building things, not breaking things. Learning to think about how someone might break the system means being aware of all the things that could go wrong with the software—including the components and dependencies in the software supply chain, and any known vulnerabilities.

Developers also need an understanding of what security testing is and what it can and can’t do. They also need to understand what happens during security testing—what the test is looking for, how vulnerabilities are prioritized, and how issues are mitigated.

An understanding of security best practices, such as patching the software and systems, automating routine tasks, and enforcing least privilege, also serves the development team well. Sticking to the fundamentals and keeping security top-of-mind can go a long way in reducing the risk of attack for your organization.

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.

Embracing security

Developers may not be security experts, but that doesn’t mean they can’t learn the basics to ensure they are building security into their applications. Watch the webinar “What I Wish I Knew About Security When I Started Programming” to learn how to help developers embrace security as part of their everyday lives.

Continue Reading

Explore Topics