A few weeks ago I wrote about how we handled PHP2Shell. The week after, another critical advisory arrived, this time for online stores on Drupal Commerce. Advisories like these call for quick action. But how do we find the weaknesses that are not yet known? We have been working on that since early 2026. Now we offer Proactive security to our clients. The testing runs on Frontkom's own hardware.
Why we started
When a security advisory arrives, we have to check whether the solutions we maintain are affected, and fix them where necessary. It is an important part of ongoing maintenance.
Advisories usually concern components used by many. They tell us less about the code written specifically for one solution, the integrations with other systems and how everything is configured. Weaknesses there we have to look for ourselves.
AI makes it possible to examine solutions faster and more systematically. That gives us new tools in security work, while we also have to assume that attackers use the same possibilities.
We therefore wanted to find a way to test more often, with clear limits on what the tests are allowed to do.
What Proactive security does
The test combines a systematic review with exploratory testing.
In the systematic part, the agents use security requirements from OWASP ASVS 5.0 levels 1 and 2 and test methods from OWASP WSTG 4.2. ASVS describes security requirements for applications, while WSTG gives guidance on how security can be tested. The agents also check technology and versions against current advisories from the Norwegian National Security Authority (NSM) and CISA.
The report shows which requirements were checked, the results of the checks and what the test does not cover.
The test can be run with different levels of access:
- Without login (black box), the agents examine what is available from the internet.
- With login (grey box), they also examine what users with different roles have access to, and whether the access restrictions work.
- With access to the source code (white box), they can also examine how the solution is built, and use this to target the testing.
Access and scope are agreed before the test starts.
In the exploratory part, the agents follow leads to possible weaknesses. They connect observations and investigate further where something looks vulnerable. Here they also look for flaws in features and integrations built specifically for the solution. This is where the test differs most from a vulnerability scanner, which looks for known weaknesses in shared components.
The client gets a summary report with findings, severity and recommended actions, along with a detailed overview of the test coverage. The findings are described so that a developer, or an agent using AI, can use them as a basis for fixing.
After the flaws have been fixed, we can test again to check whether the actions have solved the problem.
A focus on safety
Security testing can affect the solution being tested. Much of the development work has therefore been about limiting the risk, especially when testing in production.
The language models run on Frontkom's own hardware. Information about weaknesses in clients' solutions is not shared with any AI vendor.
Each test runs in an isolated environment with its own firewall, which only lets traffic through to the addresses the client has approved. The boundary is therefore enforced outside the agents' own instructions, and the agents cannot switch the barriers off.
The standard test is designed to avoid changes to client data, and password guessing is not included. If the solution shows signs of load, the test reduces its activity.
The scope is agreed before we start, so that the client knows which parts of the solution will be examined.
Testing with login should be done against a test environment. Platops, an internal team at Frontkom, follows the test and can stop it.
We tested ourselves first
Before we offered the service to others, we tested our own solutions, including frontkom.com. We also tested solutions we maintain for clients.
The tests found weaknesses that we fixed. On frontkom.com, the first fix did not hold. We discovered that when we tested again.
It is a concrete lesson we take with us:
A fix has to be checked too.
That is why we offer a retest as part of the follow-up.
Our tests have uncovered serious weaknesses, both in our own solutions and in solutions we maintain. That gives us a concrete reason to test regularly, also when there is no security advisory.
Available now
Proactive security fits before a new solution goes into production, as a regular part of maintenance, and when an advisory makes you want to know whether you are affected. It does not replace updates, nor a manual security test where one is required. The test is carried out by Platops, which passes the findings directly to the team that maintains the solution. There is no third party to bring in and no handovers to facilitate. When we test solutions we have built ourselves, it is quality assurance and not an independent test. The report says so.
If you want to know how your solution is doing, get in touch at erlend@frontkom.com.
Transparency note: This article is based on the author's own experience and judgement. AI was used as an editorial aid for structure and language. The author has reviewed the content and is responsible for it.
