Secure Software Development Habits

As mentioned in my previous post "Building Software Immunity," an application security mindset needs to be at the core of software development practices. Just as good eating habits bring nutrients into our bodies, good development practices bring internal quality and immunity into our software to help fight off any unforeseen attacks in future. This post is an attempt to explore some of these ideas and practices that can help developers or tech leads make software and, eventually, the end users secure.


Shift-Left Approach

With the rise of Twelve-Factor cloud native applications, infrastructure has become part of software applications. Development teams (leads, software developers, product owners) are building software rapidly with various CI/CD (DevOps) and IaC (Infrastructure As Code) tools. In such agile and evolving environments, security of the software can be easily overlooked. As pointed out by Richard Seiersen in A Modern Shift-Left Security Approach, incorporating security in early phases of software development has typically been costly and time-intensive. An improved approach is to embrace security features right from the beginning when requirements are formed. That is, security requirements can be augmented with user stories to emphasize these aspects in rapid development environments (for more directions, refer to C1: Define Security Requirements | OWASP).

What Is Taint Analysis and Why Should I Care?

He covered a wet, hacking cough with his hand, then pushed through the door of the ward. I reached the same door and hesitated. The Cougher had just tainted the door with his germs. If I touched it, I'd be tainted too.

These days we all know what germs are and how they're passed from person to person, and from hand to door to hand. The fact is that particularly in cold and flu season you have to regard every doorknob, and every elevator button as suspicious. You always wash your hands afterward, because you never know which doorknob is tainted with germs. You have to assume they all are.

The Problem With Code Signing Private Key Sprawl

Code Signing Private Keys Are Everywhere

People hide keys under their welcome mats, under the potted plant next to the front door, above the door jam, or maybe under that fake-looking rock next to the front walk. But why would they hide their front door key in such obvious places? If I were a burglar, these are the first places that I would check (well, I would first check to see if the front door was even locked).

But some people are smarter than this. Instead of putting the spare key in an obvious hiding place, they make a few copies and hand them out to the dog sitter, the next-door neighbor, their boyfriend/girlfriend, or the handyman fixing the washing machine. Before they know it, they’ve lost track of who they have given keys to and their house is vulnerable once again.

Code Signing Credentials Are Machine Identities and Need to Be Protected

The world is experiencing a digital transformation that is eclipsing all previous technological advancements. As more IT workloads move to the cloud, and as more IT services are containerized, they all need to be authenticated using cryptographic keys and digital certificates, or machine identities. Given the pace and scale of this new world of machines, protecting those machine identities is becoming increasingly critical to security. Although these changes affect every business, many organizations use outdated methods to protect the exponentially rising number of machine identities they now require. Those approaches simply can’t keep up.

How does this impact the security of code? There are many types of machine identities — TLS, SSH, mobile and more — that are used on many types of machines. When you look at it in this light, code is the ultimate "machine" that requires an authorized identity so that we can trust it. That is precisely why machine identities are so critical to the code signing process.