Developer vs. Hacker: Two Sides of the Same Coin?

Years ago, when I started my career as a writer, I became a journalist dedicated to informing people and serving the public interest. Later, I became a writer in a marketing role, dedicated to creating content that informs prospects and serves customers. I call upon the same skills to write blog posts and whitepapers that I once did to write news articles.

Likewise, journalists may use their skills to switch to a career in public relations, writing press releases and setting up interviews with journalists. These days, the lines between journalism and PR are blurring, with paid advertorial content appearing alongside editorial content. Writers and PR pros are two sides of the same coin.

The same goes for developers and black-hat hackers, who have a lot more in common than you might expect (or maybe choose to acknowledge). Both need to know how to code, obviously. And they may both develop software. Whereas a developer for Facebook might be working on an application for secure messaging, a criminal hacker with the same cryptography skills might use them to create a new strain of crypto-ransomware. A hacker could even work for a cybercriminal enterprise that looks and behaves a lot like a legitimate business, with teams of programmers writing code for exploit kits, other people writing spam and “customer service” employees who respond to orders and complaints. Hackers working for criminal enterprises face some of the same challenges as developers at legitimate businesses. For example, feature requirements and deadlines.

From the outside, a developer working inside a legitimate organization or software vendor, and a hacker who spends his weekends picking apart that developer’s code, look like two peas in a pod. Instead of being polar opposites, they are more like yin and yang. One probably gets paid a good salary to stay within the rules and the other one plays outside the rules.

We see ambiguity in the word “hacker” itself. Who is a hacker? It’s become synonymous in recent years with “cybercriminal,” but it’s not really a pejorative term. Hackers can also be innovators who push boundaries, tinkering with existing technology; or building something paradigm-shifting, like Steve Jobs, Bill Gates or Mark Zuckerberg. At Veracode, we celebrate our annual Hackathon, involving staff from developers and engineers to marketing and sales, who work on self-directed projects that can take the form of useful programs or off-the-wall projects. Hackers can be good, bad or somewhere in-between.

Beyond the sometimes ambiguous differences between them, there is one major element that sets today’s developers apart from their brethren in the shadows – quality. Unlike developers, cybercriminals don’t care about the quality of their code, as evidenced by recent examples of ransomware with faulty encryption that can be cracked. With badly-coded ransomware, some victims can get their files back without paying the ransom (while other cryptographic errors in ransomware hurt even the victims who pay, when a decryption key doesn’t work). Cybercriminals often get caught through shoddy work, by failing to conceal their IP addresses, locations and other identifying breadcrumbs.

Developers might suffer the consequences of messy coding, too. But at least they work within rigorous processes put in place to catch coding errors. Many development teams today are adopting DevOps and, increasingly, security is a requirement. Developers use tools like static analysis and sandboxes to scan for coding errors at multiple stages of the continuous development/continuous deployment lifecycle. In DevOps environments, developers are being measured and incentivized to write better and more secure code with ongoing eLearning.

At the end of the day, you can tell a professional developer apart from a “hacker” by asking them one question: do you want to write great code, or “good enough” code? To help you create an environment that ensures quality and secure code, we’ve developed five principles for securing DevOps – check them out and share them with your developer peers and DevOps managers.