Home 4 min read

0x007 - Shift Left Security ⏪

Hi, y’all! This is the seventh issue of unzip.dev, a newsletter dedicated to developer trends, where we unpack trending dev concepts. My name is Agam More, and I’m a developer generalist. I’ll be posting every few weeks, so if you haven’t subscribed yet, go for it.

I know this is a very high-level trend, one that might appeal to some of you and not as much to others. I’m still figuring out what spectrum of subjects unzip.dev should take on, as I also want to discuss specific technologies (like we touched on in 0x001) in addition to trends like this one. I’d love to hear what you think - just reply to this email! I promise to reply :)

Shift Left Security

“Secure from the start.”

Synonyms: (part of) DevSecOps.

TL;DR:

  • Problem: Security incidents in production are very costly.
  • Solution: Introducing security checks and fixes earlier in development.
  • In Sum: Fixing security problems sooner is easier and cheaper. The whole industry is moving in that direction. Just remember, it isn’t a “one size fits all” solution to every security need.
Lock icons created by Freepik - Flaticon

How does it work? 💡

After some planning and deciding on security policies, automatic tools are integrated into IDEs, git-based developer workflows, and CI/CD build pipelines.

Examples of tools are:

These tools must be part of the routine build pipeline to ensure they are addressed before code reaches production.

Use cases ✅

Every modern product should be security-aware, so this isn’t a suggestion for a specific industry or one type of product.
  • Teams that want to cover security issues at every level of the SDLC.
    • Teams that want more automated security testing.

Why? 🤔

  • Remediation: Finding a security vulnerability during development is much better than finding it in production.
  • Cost savings: Saving security costs by shifting the bug fixes and manual audit work to automated tools in the build pipeline.
  • Compliance: Shifting automated security checks to the early stages of development can complement your compliance readiness.
  • Developer security “training”: Developers can learn from warnings and apply best practices in the future.

Why not? 🙅

  • Cost: To implement holistic shift left processes, you need a plethora of tools, which might be very costly in aggregate. In a more mature organization there is the cost of figuring out ownership, responsibilities, milestones, and metrics, which is needed to be taken into consideration.
  • Not absolute: It might instill a false sense of security. Tools are great, but often, the 1% of problems that they can’t find are the ones that will hit you the hardest.
    • Production: Checking production is still relevant, such as behavior analysis, WAFs, monitoring, pen testing, and more production-centric security tools.
    • Business logic: To date, I still don’t know of a real solution that completely saves your butt from business logic vulnerabilities - please reply and let me know if you do. Bug bounties and pen testers are still invaluable.
    • False positives: “Alert Fatigue” can lead to security problems propagating to production.
  • Increased build time: Adding more tools and checks, especially fuzzing and DASTs are known for running for extended periods of time.

Tools & players 🛠️

  • Snyk - Developer-first cloud-native application security platform with plenty of IDE integrations (disclaimer, @liran_tal gave his insights on this issue).
  • Palo Alto Networks: Prisma Cloud - Palo Alto Networks’s shift left security suite, previously bridgecrew (disclaimer, I used to work in the XSOAR department).
  • WhiteSource - A platform designed to automate open-source security.
  • Checkpoint DevSecOps - Checkpoint’s shift left offering.
  • GitHub’s CodeQL - query code as data, very helpful to find vulnerabilities 🤩 pretty awesome!
  • ShiftLeft.io - (Congrats on the naming) AppSec platform for developers.
  • FOSSA - The specific open-source vulnerability management product offering.
  • aqua - AppSec suite of tools (serverless, containers, and more).
  • datree - Kubernetes shift left security solution (with open-source offering).
  • sonatype - Suite of shift left security products.
  • veracode - Many code security analysis products.
  • enso - Helps coordinate many shift left security products together.
🤠
My opinion: As an ex-security professional for many years, I can attest that having good security pipelines is really helpful. But I still insist that production systems have mitigations in place since shift left isn’t a “be-all-end-all'' solution for security. Rather, it is a positive mind shift that needs to be combined with tried-and-tested approaches and tools. I would use snyk’s free tier (via IDE) and WhiteSource Bolt (for GitHub) to tackle the basics, as their integration cost is quite minimal. Over time, when the need arises, I would add other tools depending on pricing and threat modeling.

My opinion was not sponsored by any company or person mentioned in this issue.

Forecast 🧞

  • Large language models (0x006) in action: It will be interesting to see shift left tools utilizing LLMs (advanced code scanning, for example). GPT-3 codex is one of the first enablers for such products.
    • AI improvements will probably impact business logic vulnerabilities.
  • Everything is shifting left: I believe that many more concepts will “shift left” to become part of our daily dev lives. Shift left is already done with testing and DevOps, other aspects out of the typical developer boundary can also be shifted there.

Extra ✨

Some extra information that is related to the subject matter:

EOF

(Where I tend to share unrelated things).

I realized that some of you don't know, but unzip is an open-book, you can follow the journey on indiehackers.com✨.

Thanks 🙏

I wanted to thank everyone here for valuable insights on this issue: @royhax91 (Cybersecurity generalist, teaching awesome cybersecurity courses and workshops), @liran_tal (a GitHub star, Director of Developer Advocacy at Snyk & much more!  Had some amazing insider insights on this topic), Batya (a real English-speaking person that is also data-scientisting currently) and last but not least @TomGranot (the best DevRel I know @Lightrun).