Scanning and Shifting Left

Back in Chapter 4, the pipeline ran automated tests on every change to catch bugs the moment they appeared. The same machinery can do something else at the same time: check each change for security problems. That automatic checking is called scanning — a tool reads the code and what it depends on, looking for known weaknesses.

The other half of this topic is about when those checks run. Catching a problem early, while the change is still small and fresh in Maya's mind, is far easier than catching it at the end. Moving the checks toward the start of the pipeline instead of the finish has a name you'll hear constantly: shifting left.

ChangeMaya pushes a commit

→

Security scanruns in the pipeline

→

Pass / flaggedcaught early

Automated scanning

A scan is a machine reading the change and comparing it against a list of known security problems. Just as an automated test asks "does the app still behave correctly?", a security scanner asks "does this change contain anything known to be risky?" — and it runs every time the code changes, without anyone remembering to start it.

Because it's automatic and fast, it fits naturally into the pipeline you already know. The scan becomes one more step the change has to pass, right next to building and testing.

What scans catch

Scanners look for a few common kinds of trouble. They check the outside code your app depends on — the ready-made building blocks every app reuses — for versions with known holes. They look for secrets accidentally committed into the code, the exact mistake from the last topic. And they flag risky settings, like a database left open to the whole internet.

One honest limit matters here: a scan only finds known problems — the ones already on its list. It cannot catch a brand-new weakness nobody has discovered yet. That makes scanning genuinely useful and, on its own, never a guarantee of safety.

Shifting left

Picture the pipeline drawn left to right: writing code on the left, releasing to users on the right. "Shifting left" means moving a check from the right-hand, late end toward the left-hand, early end — running it as the change is made rather than just before release. It's the same catch-problems-early idea from continuous integration, now pointed at security.

Think of an airport. You can try to catch every problem with one frantic check at the gate, or you can build screening into check-in, so issues surface early and calmly, one at a time. Shifting security left is choosing the second arrangement: small checks up front instead of one bottleneck at the end.

Another gate in the pipeline

Put those together and security stops being a special event. It becomes another automated gate the change passes through — build, test, scan — each one able to stop a change that doesn't measure up, exactly as Chapter 2 described a pipeline working.

That is the practical face of the DevSecOps idea from the start of this chapter: not a meeting or a final sign-off, but checks woven into the everyday flow. The hands-on side — reading what a scanner reports and deciding what to do about it — is where Security for Beginners and the CyberSecurity Deep Dive pick up; here, the takeaway is that security can ride the same pipeline as everything else.