How to fix vulnerabilities in applications
Protect a web application, whatever its language: limit what a vulnerability lets an attacker reach, be alerted immediately, check your dependencies, apply every critical fix on the day it is published.
Updated on 5 min read
Sébastien Nobour
Founder of DEVEDANOS
A shared spreadsheet that runs a whole part of the business. A personal cloud storage account used to swap files with a client. An AI tool into which someone pastes a document to get a summary. None of these tools was chosen by the company, and yet the work depends on them.
This is called shadow IT. The NCSC, the UK’s National Cyber Security Centre, looks first at why it appears. Its answer goes further than blocking it.
The NCSC gave a definition in 2023. Shadow IT is the name given to “unknown IT assets used within an organisation for business purposes”.
According to the NCSC, shadow IT is “normally due to staff struggling to use sanctioned tools or processes to complete a specific task”.
It is widespread. Gartner, a research firm specialising in information technology, put a figure on it in its March 2023 cybersecurity predictions. According to Gartner, in 2022, 41% of employees acquired, modified or created technology outside the visibility of their IT department. The firm predicted 75% by 2027. These figures cover companies in general, not small businesses in particular.
The NCSC gives two examples: sensitive company data stored in personal cloud accounts, and messaging or video conferencing services the company has not approved, used with no monitoring in place. The spreadsheet and the AI tool are two more, closer to a small business’s day-to-day work.
A spreadsheet needs no purchase and no installation: it is already on every computer. When the company’s tool does not do what the team needs, someone builds a spreadsheet to fill the gap. The file proves useful, then indispensable.
The business then rests on a file nobody chose, with the errors a spreadsheet does not flag. Once it has become a whole team’s tool, it is better to turn it into a web application than to ban it.
Shadow AI is the same thing with AI tools: an AI assistant the company has not chosen is used to write, summarise or translate.
In our view, the risk lies in the documents people paste into it. If they contain personal data, about a client or an employee, the company no longer knows who it has been entrusted to.
The GDPR deals with this for service providers. Under its Article 28, a processor does not engage another processor, such as the provider of an AI model, without the prior specific or general written authorisation of the controller. This article covers the relationship between the company and its processors, not an employee’s own use of a tool.
For the NCSC, when shadow IT is prevalent, risk management becomes very difficult, and the company has even less visibility of the potential risks. In our view, a tool the IT department does not know about is one it does not update, back up or monitor.
The second risk concerns data. Company data ends up in personal accounts, with vendors the company has no contract with. In our view, the day the employee leaves, those accounts leave with them.
The third is less visible. A tool built alongside the official one shows a need the official one does not meet. As long as it stays in the shadows, nobody knows the need exists, and the official tool does not change.
The NCSC recommends organisational measures and technical solutions, such as an inventory of IT assets and network access control. It adds two pieces of advice. Where shadow IT is discovered, it is important not to reprimand staff. And when employees use unsanctioned tools, it advises providing them with an approved, supported service that addresses this need.
In our view, this is where the lasting answer lies. Blocking a tool does not remove the need that gave rise to it: the team will find another one. Instead, ask the team what it does with this tool, and what the official tool does not let it do. If off-the-shelf software covers the need, it remains the simplest choice. If none fits the way you work, it is up to the tool to adapt to you.
At DEVEDANOS, we develop your custom software, usable within a month, for a fixed monthly budget, and we adjust it continuously as your business evolves. The budget is built with you, from your figures and your goals: together, we set the amount and the problem your application has to solve.
We start by talking with the users of your application, to understand their needs. Your application’s users work with it from the first month of development, and how they use it determines the next feature or features. Our approach starts from that use: a tool its users don’t need to work around.
And so that what worked yesterday still works tomorrow, we apply a zero-regression guarantee: every regression is fixed and covered by an automated test so that it does not come back, at no extra cost.
The source code, infrastructure, deployment pipeline and documentation are your intellectual property once the first monthly invoice is paid.
Off-the-shelf or bespoke software? Our article on choosing a software package helps you spot the activities where your teams adapt to the tool, and those where the tool has to adapt to you.
Have your teams built their own tools alongside the company’s? Shall we talk?
Protect a web application, whatever its language: limit what a vulnerability lets an attacker reach, be alerted immediately, check your dependencies, apply every critical fix on the day it is published.
Should you enable or disable WordPress automatic updates? We advise against the ones WordPress applies on its own to plugins and themes, without any testing. A host that tests each update before applying it can handle them; without one, update one plugin at a time, then check the site.
On 21 October 2026, PHP fixed two critical vulnerabilities, on the same day as GitLab and Node.js. Who is affected, what to do that same day, and how to limit the damage a vulnerability can do.