Skip to main content

Where Code Meets Platform: Baking Security Into Every Build

· 5 min read
Gonzalo Suárez
Gonzalo Suárez
Junior Platform Engineer

Shift-left Philosophy: Why Security Matters​

You might remember the recent supply chain attack that hit NPM packages — maybe your team even felt the impact. It was a good reminder that one vulnerable dependency can ripple across entire systems.

Modern software is a tangled web of dependencies, containers, and distributed codebases. Things move fast, and it’s easy to miss outdated packages or accidentally introduce new risks. All of that adds up to a big security challenge.

Shift-left security aims to solve this — catching issues early in the development process, before they make it to production. It’s not just about fixing problems; it’s about preventing them in the first place.

So, if security needs to start early, how do we actually make that happen? That’s where Application Security Testing (AST) comes in.

Application Security Testing: What It Is and Why It Matters​

AST tools aren’t just there to tick compliance boxes — they help teams find problems early, reduce risk, and protect users before code ships.

There are a few key parts to it:

  • SAST (Static Application Security Testing): Scans your source code for insecure patterns like unsafe inputs or weak function calls — all before your app even runs.
  • Secret Scanning: Finds sensitive information (API keys, passwords, certificates) that might have accidentally ended up in your repos.
  • Software Composition Analysis (SCA): Checks your dependencies and open-source libraries for known vulnerabilities or outdated versions.

Together, these tools give you a clear view of where your risks are — across code, dependencies, and secrets. More importantly, they don’t just tell you something’s wrong; they help you stop vulnerabilities before they become real issues.

Integrating Security into Your Workflow​

Having the right tools is important, but the real magic happens when you bake them into your everyday workflow. By plugging AST tools into your CI/CD pipeline, every commit, pull request, or build can be scanned automatically.

That means security checks happen as part of normal development — not as an afterthought. Issues are caught early, feedback goes straight to developers, and teams can shift left, turning security from a one-time event into part of their daily rhythm.

Automating these checks also cuts down on human error, keeps standards consistent, and helps teams build a culture of proactive security that grows with the organization.

In practice, this means security becomes a natural checkpoint in your delivery flow. For example, imagine your CI/CD pipeline detects a critical vulnerability in a dependency just before deployment. The release is automatically blocked — frustrating in the moment, indeed, but it might have just prevented a production outage or data leak. With clear reporting and well-defined exceptions, the team can decide whether to patch, replace, or (in rare, justified cases) move forward with a temporary risk waiver. That’s real-world shift-left security: catching problems when they’re still easy to fix, not after customers are affected.

Tools Used​

Once the workflow is in place, the right tools make it stick. Here’s what we use to cover all the bases:

  • Trivy (SCA): Scans container images and dependencies for known vulnerabilities before anything hits production.
  • TruffleHog (Secret Scanning): Spots secrets, credentials, and sensitive data accidentally pushed to your repos.
  • Semgrep (SAST): Uses custom static analysis rules to flag insecure code patterns and enforce best practices.

We’ve integrated these tools directly into the CI/CD pipeline, so every commit or pull request triggers automatic scans. Developers get quick feedback through clear reports, so they can fix issues fast — without slowing down the build.

By combining automation with visibility, these tools don’t just find problems — they help teams build more secure software by default.

Minimizing Risk: Do You Really Need That Dependency?​

Every new dependency is a potential risk. Even popular libraries can bring in vulnerabilities, and unmaintained ones often turn into hidden liabilities. This is what we call your risk surface — all the points where your application could be attacked.

To keep that surface small, start with one simple habit: ask, “Do we really need this?” before adding a new dependency. Check if it’s maintained, trusted, and necessary. The same goes for old dependencies — review them regularly and remove what you don’t use.

Tools like SCA scanners make this easier by flagging known issues automatically, but awareness and judgment still matter most. Reducing risk isn’t just about fixing what’s broken — it’s about keeping things clean in the first place.

Starting Small and Staying Realistic​

Rolling out all these practices at once can feel like a lot — especially for smaller teams. But security doesn’t have to be all or nothing. It’s better to start small and grow steadily. Begin with the areas that matter most: core repos, key dependencies, or code that handles sensitive data. From there, add more automation and rules as your team gets comfortable.

Education is just as important as tooling. Developers should understand what scan results mean and how to act on them. Over time, these habits turn security from something “extra” into something everyone naturally does.

As your setup matures, it helps to define which checks are mandatory and which are recommended. For instance, secret scanning and dependency analysis might be non-negotiable in all projects, while SAST could start as “recommended” until coverage improves. This distinction sets clear expectations — security isn’t about blocking progress, but about managing risk with context.

Over time, these habits don’t just make your software safer — they build trust. Each secure release reinforces your team’s reliability and your company’s reputation. Security becomes part of your brand, not just your build.