In GitGuardian's first digital conference, CodeSecDays, security leaders from multiple leading companies like Snyk, Chainguard, Doppler, RedMonk, and more came together to share the latest in code and application security. As the CEO and founder of GitGuardian, Eric Fourrier said, “No organizations in this world can grow without software and the developers to build and maintain it.” But the reliance on software has a dark side, with malicious actors increasingly attacking our supply chains to extort and disrupt operations. This article will explore the key takeaways from the CodeSecDays event.

> Miss the event? Don’t worry; you can still view each presentation from our YouTube channel too.

Can we create a world with no security issues?

One of the highlights of the event was undoubtedly the panel discussion that brought together five security experts from different backgrounds to discuss if it was possible to end up in a world with no security issues.

While I’m sure we can all agree this is not something close to being a reality, it does force you to consider what it would actually take and what are the most prominent issues in security right now.

  • Sonya Moisset from Snyk highlights the importance of removing the silos in most organizations between the developers and the security team. Solving security issues will always involve all teams working collectively on their relevant topics
  • Eddie Zaneski from ChainGuard focused on gaining visibility into the tech stacks “Companies don’t know what's running in their tech stack” As an example, Eddie discussed how it took one company two weeks to come up with a plan, just a plan, on how to handle the Log4J vulnerability because they didn’t understand how they would be affected.
  • Rachel Stephens, the session moderator and analyst from Red Monk, also gave a great response claiming we need to “Make the right thing the default thing,” which relates to how often the default settings in tools and frameworks are very commonly vulnerable.

Creating effective security training

A world without security issues will ideally be a world with more security training, particularly for developers. But it came up multiple times in the panel that current security training is very often ineffective; security training is often very generic and boring and isn’t customized for the business or even the trainee. Kaysar Daher, Security Engineer at GitGuardian, mentioned that “Security training is often off the mark.” Sonya added to this by giving some good insights into how to make security training more effective such as leaning on developers' natural competitive spirit. “Gamify the process when educating developers,” and add to this by making sure you have the right context for the audience when you are building out these training sessions.

So what can we do?

Of course, it was wildly acknowledged that a world without security issues simply isn’t possible right now we can still look at what key steps would take us closer to this. One key thing that the panel agreed on is moving away from secrets like API keys which are heavily relied on in the development process. “More machine identity authentication and more dynamic secrets where that isn’t possible,” Nic Manoogain from Doppler quickly outlined, which was backed up by Eddie Zaneski. “Machine identity is critical, getting rid of keys and secrets for developers. Why would I want long live keys? Even though I trust GitHub, I still wouldn’t want them with a long-lived key to my castle.”

This panel was a fantastic start to the conference as it immediately forced us all to think outside the box of security; the standard isn’t cutting it, so we need to go beyond. But also, what I loved about it is that it was not just painting a pessimistic view of security; there were many actionable takeaways on how we can improve security.

Your attack surface just got bigger - a look at the security Iceberg with Sonya Moisset from Snyk

We can’t secure what we don’t know exists. Sonya Moisset's presentation was certainly another highlight of the event and looked at how deep the security challenges in modern applications actually are. The iceberg is a perfect security analogy that does regularly come up in security. It shows that while we know what's on the surface, most of the vulnerabilities come from what we can’t see below the surface. Sonya's talk looked at the four core layers of security we can find in our applications.

Layer 1. Applications code
Layer 2. Open-source libraries
Layer 3. Your container & Runtime dependencies
Layer 4. Infrastructure configuration or IaC (infrastructure as code)

“Our application code is only 10 - 20% of our codebase”

“80 -90% of our codebase is from opensource libraries, and all of these layers can bring potential security vulnerabilities,” Sonya Moisset

One of the key areas we need to focus our attention on is making sure we understand the vulnerabilities of our open-source libraries and also understand how attackers are able to turn these malicious. Two common attacks Sonya talked about were typosquatting and malicious packages.

  • Typosquatting attacks - bad actors push malicious packages to a registry with the hope of tricking users into installing them
  • Malicious packages - inject malicious code into a software product to compromise dependent systems down the chain

How can you start to understand if you have security vulnerabilities below the surface? For this, Sonya explained Software Composition Analysis (SCA). SCA focuses on identifying the open-source libraries within an application and reviewing if there are any known vulnerabilities. Using SCA gives us visibility into what is hidden below the surface so we can actually make informed security decisions.

Answer the Unanswerable with AppSec Metrics and Getting Management Buy-in

Cenk Kalpakoglu, the CEO and founder of Kondukto, took to the stage to give an absolutely refreshing and extremely important talk. Getting management buy-in for security programs. I’m sure most security professionals will agree that security is often underfunded in an organization; often, this is because security leaders are not telling a compelling story to get buy-in from management. This talk explored what metrics paint the best story for getting buy-in from management to get you the budget you need to be effective as a security leader.

The first takeaway came when Cenk said something that could be provocative in certain security circles.  “Business context and business needs should change the approach you choose for your security program.” This isn’t to say limit security because of it, but businesses are different, and linking security with the business will get you the best chance of getting the budget you need.

So what metrics actually matter when presenting to the board? Below are some of the key points Cenk made on what to focus on when getting management buy-in

What metrics matter:

  • Triage Percentage

How many of your incidents are triaged (evaluated and categorized). This is particularly important in finding our security bottlenecks

  • Missed SLAs

Service Level Agreements (SLAs) look at what is fixed and at what time. Focusing on where these are missed will outline where investment is needed most.

  • Vulnerability burn-down

The number of vulnerabilities alone does not provide guidance for AppSec teams. You need to look at the type of open and closed vulnerabilities to show where the results are and what needs improvement.

  • Remediation metrics

Time to first response, Time to first action, Time to remediate. These all show the most important stats. How the investment in security tooling and teams translate into results. Ultimately what the board wants.

Showing these metrics alone isn’t going to give you instant success in getting the buy-in you hoped for. It needs to be told and displayed in a compelling story. Cenks tips for this were to:

  • Visualize data
  • Identify the key metrics
  • Increase collaboration
  • Demonstrate ROI

This talk is a must-watch for anyone wanting to build an effective security program but struggling to get the resources they need (most like everyone in security).

The Power of SecretsOps, a dive into managing secrets with Nic Manoogian

Secrets, like API keys and credentials, are the glue that ties together modern applications. But managing them isn’t easy. SecretsOps is operations behind how mature organizations will manage their secrets. Nic Manoogian, the Senior Software engineer at Doppler, broke down the different layers of SecretsOps with some key insights into each layer.

  • Secrets Storage

Secrets need to be stored somewhere. Often they get sprawled across different machines and systems. The first step of SecretsOps is to store secrets in a central system creating a single point of truth. “Are your secrets stored in one place, and do your developers know where that is”

  • Secrets Governance

Governance is the process of who has access to secrets and what they can do. There is a lot of privileged access that developers get by default, for example, access to secrets in production. But often, this isn’t necessary. “At Doppler, no developers have access to production secrets”.

  • Secrets Orchestration

When your secrets are stored in one place, but they need to be used, so they inevitably need to move from storage to runtime access. In a lot of companies, this is a manual process, but good secret ops will be automated. The fewer humans involved, the better. “You have your source of truth, and you use automation to sync between where they are stored and where they are used”.

  • Secrets Lifecycle

Secrets should be rotated regularly, but this can be scary. Often you lose track of all the places a secret is stored, which can mean you get outages. Using tools and automating the process means you can have confidence leading to more secure and regular rotation. “With automation comes confidence”.

  • Secrets Observability

The final stage, and one of the most difficult to implement, is observability. Who can see and who has seen the secret “Human and machine.” Every time a secret is read, it increases the chance of a leak. A good question to ask is, “Has a human ever seen this secret? “ if yes, perhaps you need to consider your observability.

Wrap up from a day of security

CodeSecDays started with the ambition of dreaming of a world with no security vulnerabilities. CodeSecDays put together a series of presentations on how organizations can take a step forward toward this goal. The conference not only addressed some of the biggest challenges we are facing in the community, it was also full of actionable steps organizations can make to work towards making security vulnerabilities a thing of the past.