How I Shifted My Thinking and Coding to the Left – The New Stack

I. Where we have been

Melissa McKay

Melissa McKay is a developer advocate for JFrog. She is active in the developer community, chair of Interoperability SIG under the Continuous Delivery Foundation, international speaker, author, Java Champion, Docker Captain, and cheerleader for safe coding.

I’ve had a variety of experiences over my career, wildly different expectations based on skill level from simple intern to senior engineer, as well as differences between a small company/small team and a large company /great team. I am grateful for the opportunity to have started in a position where I learned to wear many different hats. I learned about the benefits of CI quite early – almost 15 years ago! I was trained in extreme programming, which brought me into the world of sprint planning, pair programming and retrospectives, seeing features and bug fixes all the way from planning to to publication.

I thrived in that environment, but looking back, I can honestly say that our development pipelines were relatively simple compared to what I see today. At that time, I was never involved in anything that happened after the release. And there was nothing security related that I was dealing with before that. I assumed it was in the hands of the ops or security engineers at the end of the pipeline, maybe even after deployment. If anything were to be discovered, we would go through the planning stages again to incorporate an update into our development cycle. Seems a little late in the game, right?

Many developers have seen a lot of change over the past few years when they transitioned to DevOps teams, and they should expect more. It feels like more and more responsibility is shifting towards us. I don’t see it in the same way as just more work and higher expectations, but more power to make better decisions about the software we’re developing – working smarter.

Developers are in a hurry to get out of their silos. Gone are the days of throwing code changes over the wall and hoping for the best. While the details of software coding and design are always understood to be within our area of ​​expertise, we must also recognize the details of the delivery and deployment process. This includes knowledge of our pipelines and basic security concepts. Having a better understanding of the process our software undergoes as it encounters deployment, we are better able to efficiently and effectively design the means to achieve this.

Several years ago, I attended a security training program for developers. A big part of that was rehashing responsible coding, supporting the code I had written, and making sure I wasn’t building any obvious welcome mats for attackers. The training included defensive coding techniques for common attack vectors such as cross-site scripting, SQL injection, and credential leaks. There has been talk of monitoring packages and libraries with known vulnerabilities, but in hindsight this has not been emphasized enough.

Then came the 2017 Equifax breach, then various dependency injection attacks, such as the SolarWinds hack, log4shell, spring4shell, and rogue developers (to name a few) corrupting their own open source packages!

II. Where we are

Massive amounts of information has been collected on individuals with the aim of serving the public with more efficient and effective applications – personal information abounds on social media and logging into your online banking account to get an up-to-date balance is now the minimum expectation. of good service.

The quantity and detail of this type of information attracts criminals. As long as there is a possibility of accessing it, the attackers’ attention will not dissipate. Flaws in software are now widely publicized and embarrassing to organizations if preventable measures are discovered to have been either not prioritized or ignored. The consequences for consumers have steadily increased in recent years. To put it simply, there is now a very personal cost to developers, as we also take advantage of today’s technology and software to enhance and benefit more from our own daily lives.

Security breaches have become increasingly common, or at least more frequently reported in the media. It has become apparent that most of our software falls short of the bar when it comes to strong security practices. And as pointing fingers fly in search of who to blame, more are expected to land in the developer’s direction.

What can we do? It is no longer enough to bask in satisfaction than the software we have developed works. Now we need to make sure it works responsibly.

First, let’s understand some of the reasons why we are in this predicament today. Besides the existence of masses of personal information, the following are also contributing factors:

  • With our desire to reduce deployment time, we automate our pipelines. It’s not negative at all. However, the desire for speed and automation does not and should not replace the effort required to test our applications. We seem to have lost some of the art of testing, and paths other than the “happy path” sometimes leave our application exposed.
  • With the shift to cloud-native application development, developers are getting more involved in packaging applications into images. Tools have been created to help with this process, but obscuring the details leaves some major attack vectors open when using open source images and other third-party images come into play.
  • Developers are encouraged not to reinvent the wheel. The availability of third-party libraries and their sheer number has led to an explosion of dependencies that we regularly integrate into our applications.

We’ve learned that paying attention to security flaws earlier in our development process makes a huge difference. We may not be able to predict future vulnerabilities, but we can certainly use the knowledge gained from previous attacks to prevent repeated infiltrations due to the same issues. The saying “fool me once, shame on you; fool me twice, shame on me” comes to mind. We have no excuse when the information is available to us.

This does NOT mean that the responsibility lies entirely with the developers. We rely heavily on our security engineers and operations staff to not only help us put safeguards where appropriate, but also to help collect and maintain security information to begin with. DevSecOps, anyone?

My main concern, however, is that as developers become more involved in building cloud-native applications and packaging their applications in containers, we are increasing the possibility of unintentionally packaging existing vulnerabilities. Not only are we used to pulling frameworks and related dependencies that we have become comfortable with, but also pulling parent and base images from public sources!

Worse still, some of this happens automatically behind the scenes via plugins that intentionally hide these details. The intention is good, mainly an attempt to ease the developer’s workflow, but we really need to be more aware and careful about what we’re doing. My thoughts wander to this random flash drive lying innocently on the sidewalk.

III. where we should be

The security space has evolved and improved considerably over the past few years. Vulnerability databases continue to grow and provide the information we need – sources such as the US Government’s NVD and Risk-Based Security’s VulnDB, as well as other public safety bug trackers and of CVE, are invaluable.

Using the combination of these resources along with increasing our knowledge of how our software is built with regards to dependencies, open source and other third party resources, will allow us to significantly improve our protections. Much of this responsibility finds its way directly in front of the developers. We are in an excellent position to begin the process of filtering and detecting vulnerabilities directly from our development environment!

Knowledge is power. It’s undeniable. But it can also be quite scary if you don’t know what to do with it. The next step after collecting information is to analyze it, and this is when important decisions are made. The amount of data we currently have is overwhelming. Now is the time to focus on curating that data and then making sensible recommendations based on the analysis.

When it comes to reviewing a list of vulnerabilities, for example, it’s naive to think we can eliminate them all. It would be a sick exercise to block every record or fail every build based on a zero vulnerability policy. Instead, we need to be able to keep moving forward and make reasonable decisions based on the answers to the following questions:

  1. Does the vulnerability apply to my software and what are the consequences of exploiting it?
  2. Is there a fix available for this vulnerability, and how much effort would it take to implement and/or perform the necessary upgrades?
  3. Is this vulnerability severe enough to halt production?

I think some of these decisions are best made by security specialists rather than developers, and that’s where the importance of strong security policies comes in. What I’m looking forward to as a developer, it’s more advice on when to sound the alarm. CVSS scores to help us measure severity is a good start, but it’s a work in progress (CVSS v2 vs. CVSS v3?), and there’s still a lot to do.

Overall, we are heading in the right direction. I see more and more vulnerability scanners aimed at the leftmost regions of our pipeline – the developer. I will embrace those tools that help me make smarter decisions when building my software, especially those that I can integrate directly into my existing development environment.

Detecting vulnerabilities in a transparent and simple way is a great first step. But now that I see these red lines warning me of danger… what should I do next?

KubeCon EU 2022

The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker, JFrog.

Picture by Ruben M. i Santos from Pixabay.

Comments are closed.