Why Manual Verification Still Matters

In the last few years, we’ve continuously been hearing that we should automate, automate, automate. So it might be weird to hear that manual verification still matters. Jeroen Willemsen explains to us why we still need to perform manual checks.

The Application in Its Runtime

Most applications consist of application code and external libraries that are executed by a runtime:

You’ll potentially have issues in these places:

Sponsorships Available

Sponsorships Available

Sponsorships Available

• third party libraries
• your application code
• your runtime

Third-Party Libraries

The first thing to do is to check your dependencies manually. It’s important to learn how to verify if an issue is actually a problem and how to fix it. Fixing can mean:

• replacing the library
• marking the issue as not being a problem
• changing application code to deal with the vulnerability

After that, you can start automating this process. But there are caveats. For example, not all ecosystems have proper dependency checkers. And even if they do, not finding a registered vulnerability doesn’t mean it’s not there.

Your Application Code

A great starting point for securing your application code is to use a static analysis tool, or SAST (Static Application Security Testing). The tooling here varies greatly among languages and frameworks.

When you decide to suppress warnings or errors, make sure you explain why you’re doing so. This will make it clear to anyone seeing the suppression once you’re no longer on the team.

If you’re looking at a commercial tool, test before you buy. What works for one team, might not work for another.

But these tools will never find everything. For example, a static analysis tool won’t tell you if authorization rules are set up correctly or if you’re disclosing information in errors.

Your Application

If you want to know how your backend is behaving in general, you can use (Read more...)