Missing Links between Software and Security

Sudip Kar
BerkeleyISchool
Published in
3 min readFeb 21, 2024
Photo by Radowan Nakif Rehan on Unsplash

I have been a software engineer for most of my life. I started writing code when I was 10 years old. My first programming language was BASIC (Of course the first code I wrote was to print “Hello World”). That gradually progressed to GW-BASIC and C by the time I was 15, writing simple code to print patterns, performing calculations, etc.

Fast forward to my undergrad in 2007, I started writing code in Java and it has stuck with me ever since. After graduating in 2011, I solved complex business logic for enterprise software using Java across 2 employers I have worked for till now. All this while, I was focused on just outputs. I didn't care how I got correct results or outputs as long as I got them. I am sure almost all software developers do that.

Why am I telling this story? Great Question. The answer lies in the response to a couple of questions:

If we ask someone who writes code using Java “Is there a difference between createStatement and prepareStatement methods while making a JDBC call to a database? If yes, what's that?”

Most Java developers will answer “No” to the question. Some will answer along the lines of “Better Performance can be achieved with prepareStatement”. While others might answer “The format of the query is different”. While the last two are not incorrect answers, I can guarantee very few will talk about the most important benefit of prepareStatement which is “It escapes and sanitizes the input values that are being passed to the SQL query, hence protecting against SQL Injection”. So while both these methods perform similar jobs, one is a more secure way of coding than the other. This crucial difference is neglected often while writing code for software.

The second question is, how many of us think about implementing robust input validation and sanitization of user-entered values while writing code? Improper input validation or lack thereof results in other common attacks such as Command Injection and cross-site scripting (XSS).

These are just a couple of examples out of many that reflect the need to add “security” during the design and implementation phase for any enterprise software and not after it is built and rolled out to production. We (including myself before I started on cybersecurity) as software developers are solely focused on the output rather than spreading that focus on the secure coding part at the same time. “Secure-by-Design” is one factor that we tend to miss which results in vulnerable software that is breached and exploited almost every day around the world.

From CISA article “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-byDesign and -Default.”

This problem is rooted in the early stages of a developer's life, most colleges offering computer science or software engineering consider cybersecurity as an optional or an elective course. A recent article by Jack Cable, Senior Technical Advisor at CISA stresses this point as to how this oversight is negatively affecting the world and what could be done to make sure this oversight is remedied. This is not an option or elective anymore.

Clearly, there is a missing link between software and security. My journey during the Master of Information and Cybersecurity at UC Berkeley has provided that link that I was missing in all those many years of software development. This article is intended to spread awareness amongst software developers about the need to shift our focus from just results to the path we take to get those results. That path has to be decided keeping security in mind so that the result is robust, secure, and efficient software and products.

Thank you for reading this post. If you like this article, please share it with your friends and colleagues. Also, if you have any questions or feedback, feel free to leave a comment below!

--

--

Sudip Kar
BerkeleyISchool

Software Engineer by profession. Cyber enthusiast/reader/researcher by hobby.