We do not develop software. Do we still need code security?
The most common follow-up question from mid-sized companies, answered honestly: if every application is run by someone else, there is nothing to scan. If bought software runs on your own servers, its dependencies and configuration age. And if scripts, integrations and small tools sit in a repository somewhere, you have been developing all along without calling it that.
A fair question
It comes up in almost every first conversation: we build machines, we haul freight, we run a law practice. We buy software, we do not write it. What would we want code security for? The question deserves a precise answer, not a sales answer. Our code security page gives the short version. Here is the long one, in three tiers, because the truth depends on what actually runs in the company, not on whether it thinks of itself as a software house.
Tier one: everything runs at third parties
If every application in the company is a service someone else operates, accounting, mail, CRM and file storage all from the cloud, with no server and no repository of your own anywhere, then the answer is simply no. There is no code we could connect, and we will not invent any. The security of those services rests with their providers, and the company's risks sit elsewhere: in credentials that are already circulating, in accounts that keep being used after a leak.
For that case our dark web monitoring is the right entry point, and we say so in the conversation before any proposal is written. A code analysis for a company without code would be revenue without benefit.
Tier two: bought software on your own servers
The most common situation in mid-sized companies is a different one. The ERP runs on the company's own server. The inventory system was introduced six years ago and customised twice since. The web shop is a standard product with a few extensions. Nobody in the building wrote a line of any of it, and yet every one of these systems is made of parts that age: open-source libraries for which flaws become known, and configurations with defaults nobody checks any more.
That is precisely the part of the scan that works without in-house development. The full pass matches every dependency against known vulnerabilities and checks the configuration for insecure defaults. Whether the application was bought or written makes no difference to the library inside it. And under Section 30 BSIG, operating bought systems counts as maintenance whose vulnerabilities have to be managed; what records that produces is in our article on proving NIS2 compliance day to day.
Tier three: the code nobody calls code
Almost every company that says it does not develop has a repository somewhere. In it: the script that pushes the night's exports into accounting. The integration between shop and warehouse that a former colleague built. The internal tool sales uses to generate quotes. A few automations, a connector, an extension for the ERP. That is development, even if nobody ever called it that.
And these pieces have a property that makes them more dangerous than the ERP itself: they were rarely written with security in mind. In our experience that is exactly where the hardcoded credentials sit, because the script only runs internally, and the unchecked inputs, because only one colleague uses it. The instant check finds both as soon as they sit in a connected repository. Why a secret that was once checked in has to be rotated is explained in our article on hardcoded secrets.
How to find your own tier
The question to ask yourselves is not whether you employ developers. It is: is there a server in the company running an application we installed ourselves? And is there a repository, a folder of scripts or a tool somebody built for us anywhere? Two noes means tier one. One yes means the free code analysis has something to look at: connection, inventory scan, prioritised findings, inside your own environment on request, no obligation. The findings will then say honestly whether it was worth it.
Frequently Asked Questions
We only use cloud services. What would we scan?
Nothing. Without a repository of your own and without a self-operated application there is no code to connect. For you, dark web monitoring is the right entry point, because the risk sits in credentials, not in code.
The vendor delivered our ERP. Why would we scan it?
Because the vendor does not update the libraries inside it on your server and does not check the configuration for you. Those two things age, and those two things are exactly what the full pass checks, without anyone writing a line.
Our scripts are internal only. Is that not harmless?
Internal is the argument by which credentials end up in scripts. An attacker who is once inside the network reads the internal scripts first, because that is where the keys to everything else are kept. If the scripts sit in a repository, the scan finds them.