The Best Secure Programming Practices

Nearly every organization gives secure programming practices lip service, but only an elite few make this goal a practical reality. Cyber predators never sit still. That harsh fact means that secure coding is a journey, not a destination. The best shops follow secure programming practices that building a reputation for shipping secure apps requires an understanding of human nature, coding chops, and practical planning.

Nurture a Security Culture

Before implementing a security strategy, it is imperative to understand the motivation of typical programmers. Essentially, programmers code to create features. These features may be an elegant user interface or a module that executes quicker than a competitor. No young coder embarks on a programming career for the pleasure of crafting well-formed SQL queries.

With this culture permeating an organization, security will always take a backseat to the rapid deployment of new features. Therefore, coding for security happens with rushed patches. Ultimately, customers will migrate to vendors who protect their data, and the software providers who meet this need will be the ones that survive.

Eat the Vegetables

Surviving as a software vendor thus demands attention to security at all phases of the development cycle. In its training series, IBM states the goal brazenly: Think like a hacker. Compared to their other duties, coders may understandably find hewing to recommended secure coding practices protocols as appealing as consuming broccoli. Even so, the tedious effort needed to ship a secure app beats unemployment.

Meet the SDLC

In 1970, Winston Royce helped pioneer the concept of the Software Development Life Cycle. Royce opened his paper with a six-step procedure for delivering software to a customer:

Requirements: Understand the customer’s need and the timeframe for delivery.
Analysis: Determine the hardware and software tools needed to meet the customer’s needs.
Program Design: Outline the necessary software units and the tasks they must perform.
Coding: Guided by the program design, write the application code.
Testing: See how well the code works, and then edit the code to meet the customer’s expectations.
Operations: Improve the code with the results of real-world experience.

In the following 10 pages, Royce outlined a far more sophisticated and realistic approach to software deployment, but his original outline would live on in program management lore. The computers of Royce’s era currently occupy honored positions in the Smithsonian, and his outline — now known as the Waterfall Model — will likely strike modern coders as comically quaint.

Nonetheless, there is a reason the Waterfall Model lives on: All of the steps outlined need to happen at some point in successful application deployments. In Royce’s era, software security involved locking the door to the computer center before heading home for the evening. With today’s developers, crafting a secure SDLC is an exponentially more complex challenge.

Tailor a Secure Software Development Lifetime Cycle

“No battle plan survives contact with the enemy.” That pithy military truism is a worthy foundation for any organization that aims to craft a secure SDLC. Every application development and deployment encounters unexpected events. These inevitable surprises sparked a raft of variations on the Waterfall Model, which collectively became the Agile Development Movement. Agile methods have a pair of features in common.

Involve the Customer

First, nearly all developers aim for customer involvement throughout the cycle. In some cases, the back-and-forth interactions result in an application that barely resembles the original design. A deployed app that meets the customer’s needs is the best possible validation for an SDLC.

Put the Security Commitment in Writing

Second, as with customer feedback, testing happens throughout the modern development cycle. Testing is the acid trial for an organization’s commitment to secure programming best practices. Writing a security checklist into the organization’s SDLC makes certain that security claims have equal importance with flashy feature implementations. As long as the organization guarantees security a seat at the table, the SDLC can evolve naturally with software market trends.

Include the Threat Model

Neither the Waterfall Model nor the Agile Development Movement anticipated the rise of cybercrime. With this peril, the first step in an SDLC — Requirements — must include a detailed threat model. The threat model is a frank assessment of the application’s exposed attack surfaces coupled with an evaluation of the latest cybercrime techniques. Thanks to the arms race between security professionals and cyber predators, organizations should prepare for frequent updates to their SDLC threat model.

Make the Framework a Friend

Nearly all modern web application development happens with the aid of a framework. Originally developed with the sole aim of speeding deployment, framework vendors have now become serious about security. Today, nearly every framework aims to steer coders away from the worst security practices.

Frameworks vary with their enforcement mechanisms. Ruby on Rails makes it nearly impossible for coders to violate its robust protections against cross-site scripting and SQL injection attacks. Django and Spring give developers a bit more elbow room. Microsoft’s APS.NET Core sits at the opposite end of the spectrum. In default mode, APS.NET Core is highly secure against typical attack vectors. Understanding that one size may not fit all, Microsoft supplies copious documentation to reduce the risk for developers who elect to step away from the defaults.

How should developers handle deviations from framework recommendations? The answer is to thoroughly record all departures and make this documentation a formal part of the organization’s SDLC. If a security vulnerability escapes the testing phase, this documentation will allow the organization’s coders to quickly zero in on the trouble spot. The requirement to write the documentation also makes programmers think twice before stepping outside the proven framework.

Build a Clear Case for Obfuscation

Though not necessary for every project, obfuscation belongs in every developer’s toolbox. Obfuscation is the practice of obscuring code to thwart reverse engineering. JavaScript code typically deploys in minified mode to enhance execution speed, and this process results in substantial obfuscation. Minification strips away all comments and shortens descriptive variable names down to bare minimums. If the minified code is still readable, coders can introduce deceptive variable names to throw potential hackers off the scent.

Java code is a different story. Java bytecode, the compiled result of source code, is relatively easy to reverse-engineer. Organizations with substantial investments in Java thus have a significant incentive for obfuscation measures. Several open-source apps are available to meet this need. A particularly clever obfuscation strategy is to rotate techniques with update deployments. Because web applications typically receive frequent updates, this strategy presents a moving target for would-be hackers.

Choose SOOS for Security

With developers, keeping their security skills ahead of cyber predators will be a career-long challenge. These programmers have an easier choice for their software composition analysis tool: SOOS. A SOOS scan compares every file of every project against a database of nearly 150,000 known vulnerabilities. The SOOS dashboard then highlights and prioritizes trouble spots for prompt attention.

Compliance receives the same TLC. With a SOOS scan, developers know the license status of every source file on the dependency tree. SOOS integrates with popular frameworks, eliminating migration hassles for the CI/CD pipeline. SOOS is the capable and cost-effective tool for any SDLC.