Building AppSec for solo devs, pt. 2

Previously I shared that I’m writing a “book” for devs to incorporate AppSec into their projects. I’m expounding on a few more thoughts about the tooling choices I’ve made.

Version Control & CI/CD: GitLab

GitLab is an easy choice for the foundation in this project. It’s well-known, supports self-hosting, and has CI/CD capabilities built in. It’s more resource intensive than I would like it to be, but it’s a start.

Why not GitHub?

Much of the work I’ve done in this space has been around GitHub. It’s practically the default for publishing software these days. However, the cracks are starting to show around its presence. GitHub being a SaaS/PaaS service isn’t a huge issue, but there are a few things that pushed me to want a serious alternative:

  • Intermittent outages are happening too often
  • GitHub actions is a painful environment to develop around
  • GitHub’s UI is lacking features to manage standards, policies, templated defaults across repos (Yes, template repos exist but they fall short.)
  • GitHub Dependabot is just lacking, more on that later.

SAST: opengrep

A quick, easy decision for a tool that is supposed to cover the basics. It can be deployed in CI/CD pipelines as a “security linter” on PRs/MRs, and also run locally so devs aren’t waiting on pipelines to run for a basic check.

SCA: Renovate

For now, I’m looking at Renovate for this. Not sure if I’ll stick with it, but it’s an alternative to GitHub Dependabot I see mentioned over and over. SCA is a deceptively complex capability to bake into DevSecOps and software practices, because you need it to work in three main ways:

  • On MRs/PRs to check dependencies going to production (or later staged environments)
  • Scheduled checks, to validate deployed dependencies against new vulnerability information
  • In local dev environments, so you can check for vulnerable libraries without waiting on long-running pipelines

So far, Renovate seems like a solid choice for this, but we’ll see.

Artifact Registries: GitLab, ...maybe Verdaccio, PyPi, etc.

Another reason to choose GitLab is it has capabilities for a private container registry and package registry built-in. (Again, GitHub has similar capabilities, but they are tiered features: free for public, limited/paid otherwise.) To keep system dependencies simple, I’ll try to get these working entirely within GitLab, but I mention Verdaccio and pypiserver as alternative package registries I may look to.

What's the point if public NPM, PyPi, etc. exist?

The tl;dr—I don’t see another reliable means of risk mitigation against software supply chain attacks, other than owning your supply chain. Logistically, it’s unreasonable to write literally every line of code your software will use. However, blindly relying on public sources is dangerous for production software. (Toy projects? Sure, go ham.) So, at a minimum we need the capability to store and proxy to trusted versions of our dependencies.

A full breakdown of this is out of scope for this article. Maybe I’ll write more on that later.

Vulnerability Management?

This is still a loose idea. Once all of these pieces are working together, and software is moving through the pipeline, it doesn’t take much more to ingest vulnerability data from APIs that many of these tools have. And I don’t expect already resource constrained teams to suddenly have time to triage and manage every vulnerability.

But visibility is important. It can give a small team at least a basic capability to prioritize the most important issues. For now, I’m still looking to building this with Postgres, pgadmin, Grafana, and maybe a simple web app. Maybe that will change.

Previous Inspiration

During my first role as an Application Security Engineer, my manager asked me to write a secure SDLC policy, and a maturity roadmap for the program. It was a rough time in that role, and I never got to test my ideas as I was laid off before anything was put in place. For the roadmap portion, my manager encouraged me to piece together many ideas: it started with a humble software inventory, linking it to vulnerability management info, building that into a “queryable SDLC” framework, and finally enabling AI agents to automate security testing from QA fixtures and threat intel. It was a tall order of wish lists for software attestation, I’m sure much of it naive, but I want to see how much of it works.

This idea of secure-SDLC + DevSecOps tooling stuck with me, and using this guide for my own projects is a way to test those ideas and put them into motion.