Application Security Where Software Meets the Shop Floor

It's tempting to treat application security as a software-company problem, but a manufacturer's ERP and MES integrations often hold customer pricing data, proprietary process parameters, and connections into machine-control systems that were never designed with modern security assumptions in mind. A vulnerability in the software layer connecting to those systems is a real path into operational technology, even if the machines themselves aren't directly exposed to the scanner.

A breach that starts in an ordinary web application can end up affecting a production line, simply because the two were never meant to be treated as fully separate concerns.

If your integration code and customer portal live on GitHub, GitHub Advanced Security's in-pull-request scanning fits a small internal engineering team well, since there's no separate dashboard for a lean team to remember to check. Snyk trades that tight integration for broader coverage across languages and hosting platforms, which matters more if your MES vendor's code or a legacy ERP customization lives somewhere other than GitHub.

Most manufacturers land on whichever option fits the team they already have, rather than the one with the longer feature list on paper.

Patching a dependency in a web-facing customer portal is low-risk to test and ship quickly. Patching something that touches a live MES integration during a production run carries real operational risk if the fix breaks a working connection. Set different remediation timelines for the two: fast for public-facing code, more deliberate and scheduled around a maintenance window for anything touching an active production system.

Set remediation windows by operational risk:

• Ship dependency fixes to the web-facing customer portal quickly, since testing and rolling back a patch there is low-risk.
• Schedule fixes that touch a live MES integration around production runs, since a broken connection can stop the shop floor.
• Test any patch to a machine-connected integration before it goes live, rather than applying it in the middle of a run.
• Name one person who owns the decision to delay a fix, so a delay is a choice and not a gap between IT and engineering.

If your MES or ERP integration was built and is maintained by an outside vendor, you may not control the scanning directly at all. Ask the vendor what scanning they run and how fast they commit to fixing a critical finding; if they can't answer clearly, that's worth escalating as a vendor-risk item on its own, separate from whichever tool your internal team uses for the code you do control.

A vague answer from a long-standing vendor is not a reason to look away just because the relationship predates any of this scrutiny. It's exactly the kind of gap worth raising at the next contract renewal, in writing, so it's on record rather than left as an assumption everyone quietly hopes is fine.

Federal guidance requires fixing a known exploited vulnerability within roughly fourteen days of it being added to the list¹. For a manufacturer's public-facing customer portal, that's a reasonable target to adopt directly. For anything touching an active production integration, plan the fix around your next scheduled maintenance window instead, and document why the timeline differs so it reads as a deliberate risk decision rather than neglect.

In a lot of manufacturing organizations, software risk falls into a gap between IT, engineering, and whoever manages the vendor relationship for the ERP or MES system, and a gap owned by everyone is often owned by no one in practice. Name one specific person responsible for tracking software vulnerability findings across both the internally maintained code and the vendor-managed systems, even if that person isn't the one doing the actual patching.

That single point of ownership matters most during a real incident, when a fast, clear answer to 'who's handling this' saves hours that a confused chain of email forwards would otherwise cost. Write the name down in an incident response document, not just in someone's head, so the answer doesn't depend on that specific person being reachable when something goes wrong.

Review that assignment whenever the person changes roles or leaves, rather than assuming the responsibility transfers automatically along with their old email address. A production incident is the wrong moment to discover that the name on file left the company two quarters ago.