Why we need developer tools for security and not security tools for developers

  • Understanding developers, developer tools, developer workflow and processes (AKA in the testing world: unit testing, e2e tests, stories, and above all the right tools for that)
  • Pushing traditional security processes to the “left” of the software production process (AKA: shift left)
  • Putting security tools, awareness, and practices in the hands of developers (AKA: empowering developers)
  • An org structure to support the radical shift to the left, e.g. DevSecOps (AKA in the testing/agile world: squads, guilds, matrix structure)

DevSecOps and shifting left gains

  • Detecting and mitigating security issues as early as coding time. This makes it similar to the gains already made in the software testing domain.
  • Moving from security as an afterthought to security by-design, getting better feedback at the right time of software creation: design and build phase.

Developer tools for security

  • How to build or evaluate tools for a developer-first approach? Where do we start?
  • Security tools for developers vs developer tools for security? What is the difference?
  • CI — what’s important to consider in your dev workflows and processes
  • Tooling — how to evaluate these tools in the context of your dev day to day
  • Feedback cycle — the other types of feedback cycle opportunity developers might want
  • Processes — or more specifically threat modeling meets dev, meets security experts meets product.

Does it work in my CI?

16 Essentials for building tools for developers

1. Be fast

2. Be simple

  • Textual output — no fancy reports
  • Point directly to the problem and show me how to fix it (save me from forensics if possible)
  • Fancy reports uploaded as artifacts for extra information
  • Give me the raw data and give me context
  • Don’t take too many keys, and don’t require privileged access if possible
  • Be familiar — the way the tool runs in CI should be similar to the way it runs in development

3. Don’t be rude

  • Dumping CI environment variables by mistake (which might contain sensitive tokens or secrets)
  • Don’t run with privileges you don’t have, weren’t given, or don’t need

4. Support a test matrix

5. Use JUnit as a report format

6. Consider SARIF for static analysis

7. Have output ready for deep dives

8. Be composable (AKA UNIX philosophy)

9. Be easy to set up

10. Auto-update is magic, but it’s also surprising

11. No context switches

12. Work on any OS

13. Have great documentation

14. The pit of success

15. Be responsive

16. Have that “oh cool” factor

  • Teach me things I don’t know
  • Work well with my existing tools. Install via Homebrew, integrate with Husky, work well with Vim.
  • No set up ceremonies — no “what did I do wrong” after install
  • Have somewhere I can complain, and be listening and responsive to my complaints

The various speeds of feedback cycles

  1. Speed — feedback must reach me quickly, in order to maintain my productivity, also it must not disrupt others
  2. Correctness — the feedback must be correct. Many times for security tools this means false positive and the handling of it
  3. Actionable — feedback must be actionable. For security tools this should be a clear explanation of the issue and its mitigation as well as education.

IDE integration

Precommit

CI

  1. A security risk where a material we have may end up in foreign-owned central store (e.g. credit cards)
  2. A productivity risk where we’re competing with time shares from the CI system, and from fellow engineers to review our work manually, or to block other people’s work if the branching model is such that work in various stages can block others (dev branch, but no PR branches or no concept of “PR review”, for example)

What about threat modeling?

  • Run a threat modeling session in pre-planning, like you perform all other risk-assessment activities (capacity planning, architecture and others)
  • Bring up and document evil user stories (or “misuse cases” or “abuser stories”) to serve as the working cases
  • For a more systematic approach for developing these stories (and of course based on the effort you can invest) — pick STRIDE or Wardly models to guide you through a complex and risky system
  • Tracking and applying these stories is a different kind of thing: some people go to extremes and use gherkin to write, track, and (possibly) execute these, with an ode to BDD. However, it does require a significant investment with tooling and techniques to run efficiently and properly; and again it goes back to developer tools for security (ever ran Zap as a part of a pipeline and had to automate UI? how did you deal with crashes?)

Summary

  • Teller — Secret management for developers and production workflows (which we made!)
  • tfsec — Security scanner for your Terraform code (which we sponsor and love!)
  • kube-score — Kubernetes object analysis with recommendations for improved reliability and security
  • Clair — very familiar and in use by many other security tools — static analysis for containers
  • gosec — security checker for Golang
  1. For every security tool that you know, there is probably another emerging tool that takes a developer-first approach. If not that, you can at least make sure it has features that allow you to build a developer-first pipeline with the existing tools today. You should now know what to look for.
  2. Identify your existing processes, know that once you shift-left some of them might start becoming bottlenecks. It’s a good time to experiment with lean and agile processes for your security planning too (e.g. threat modeling)
  3. If you intend to build tools for your pipeline, you know now what kind of trade-offs to take, and what to do and what not to do.

--

--

--

@jondot | Founder & CEO @ Spectral. Rust + FP + Hacking + Cracking + OSS. Previously CTO @ HiredScore, Como, Conduit.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dotan Nahum

Dotan Nahum

@jondot | Founder & CEO @ Spectral. Rust + FP + Hacking + Cracking + OSS. Previously CTO @ HiredScore, Como, Conduit.

More from Medium

Otomi Quickstart

Migrate Keycloak H2 database to Postgres on Kubernetes

How to run Podman with Hashicorp Nomad on Ubuntu 20.04 LTS

Self-hosting Unleash with Kubernetes