On the Internet, detection and reporting of vulnerabilities in software is a daily occurrence. Where do those vulnerabilities originate? Are they introduced into code by artificial intelligence or some advanced machine-learning algorithm? Nope.
Human developers create them—mostly not on purpose, but by accident. They develop weaknesses because they lack the knowledge for what causes vulnerabilities and the responsibility for security.
Security for developers is far more than just learning to hack. The security industry believes that hacking is the answer to every problem. Teach developers to hack, they say, and that will improve the security of applications.
The sad truth is that learning to hack does not teach someone to build secure software. It shows them how to break their creation, which is a useful skill, but breaking does not result in building secure software.
Here's how developers can take the lead on security in your organization.
Developers vs. security teams: That is the question
If developers are the source of most vulnerabilities, the first question to answer is, Should the burden of security fall on developers? There are two high-level answers to this question: Leave the security to the security people, or make everyone part of the security solution.
The argument for leaving security to the security people is that developers are busy. They are experts in software, and should be left alone to create beautiful things. This approach maximizes developer productivity and avoids burdening them with something outside their expertise. But it's almost impossible for security people to fix the security problems developers create without the assistance of those same developers.
Creating a fix for something at a later time is always more expensive than doing things correctly from the start. And this approach does not scale when you get above 10 developers, because for every 10 developers, you need to add an application security professional. An organization with 2,500 developers cannot support a 250-person application security team.
All together now on security?
The second option is to make everyone part of the security solution, including developers. On the one hand, developers are the software experts, and in the best position to secure the software they write. On the other, developers may spend time focused on things outside the scope of a specific user story or requirement.
The shift-left movement, which pushes security as far to the left in the development lifecycle as possible, calls for every developer to focus on security. To achieve scale in an agile or DevOps context, security cannot be an afterthought. It must be embedded in the process and people.
There is a great divide between the perception of developers and managers regarding application security. This divide is the result of a lack of education on the developer’s part. The most significant challenge to security education is that developer training focuses on the “what and how” of application security, and never explains why the developers need to care.
When starting with “why” as a core question for every piece of information developers are expected to take in, they can understand the reasoning behind a concept and the ramifications if they do not follow the principle correctly. They know outcomes instead of just a set of steps or a tool that has no context in their development process.
The most significant challenge to security education is that developer training focuses on the “what and how” of application security, and never explains why the developers need to care.
Let developers lead
The short answer is that the burden of security belongs to developers. The idea that developers are unable to handle the details of security is crazy. A developer sees the writing of software as an art and a craft, not just a job and a paycheck. Developers exist in a whirlwind of new technologies. The creation of new frameworks happens yearly, and an active developer adapts to new technology.
The idea that developers are unable to handle the details of security is crazy
The risk of not keeping up is obsolescence. The argument that developers are not smart enough or skilled enough to keep up with all the security jargon, tools, and design principles is not defensible. Developers are adaptable people by nature and will accept the challenge of security like any other challenge if you pose it to them correctly.
Some fall into the trap of thinking that application security tools can solve all problems and prevent burdening developers. The investment of hundreds of thousands of dollars goes into providing the latest and greatest tools and draws the false conclusion that this will result in lowering the burden on developers, and making the product or application secure.
The challenge with this conclusion is that the tools by themselves require large amounts of care, feeding, and knowledge on the part of the developer for success. Application security tools are not plug and play. Take a static application security testing (SAST) solution. With SAST, the scanner reviews the source code, which results in a report for the developer.
The report may contain anywhere from a few hundred to thousands of potential problems in the source code. Developers are just as burdened by tool's output as they are by an extended security process. Tools are helpful for security, but they are not the answer by themselves.
Since developers are the source of most vulnerabilities, security requires developers. The next question to explore is how much of the security burden developers should bear.
Tools are helpful for the security solution, but they are not the answer in themselves.
Make security burden-free
A burden-free security environment is the easy answer. When an organization has a strong security culture, developers understand the value of security and the risk of ignoring best practices. They know that personally identifiable information stored within the databases requires protection.
A security system that is not burdensome to developers must follow a few common themes:
- The result must have a low false-positive rate. Developers hate wasting time.
- The system should integrate into developers' existing tools and not disrupt their flow.
- The system should update all other resource allocation algorithms to provide a proper multiple of time for the developer to take on new security tasks.
- It must have a defined, measurable return on investment.
- The answer has something for developers as well as the company.
Developers may never become experts in security, and that is okay. Building a secure product does not require developers to become security experts. But developers must share a common goal of securing any product or application. All developers must have a stake in the security of the product.
Keep it about security culture
A correct security approach should not place a burden on developers. If the focus is on building a positive security culture that rewards developers for learning and doing the right thing, then developers will not see it as a burden. But if you create a negative environment where mistakes result in punishment, your developers will never see security in a positive light.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
