The rise of tooling for vulnerability detection combined with pressure driven by Vendor Due Diligence is causing a massive enterprise freezeout for non-mainstream technologies across the board. Of particular concern is the impact this will have on the adoption of functional programming in enterprise and small business B2B development.

I see now that the last 10 years were “easy mode” for the growth of new programming tools and infrastructure, with many new breakthrough technologies seeing rapid adoption. Languages like Node, Go and to some degree Scala saw breakaway success, not to mention all of the new cloud tech, NoSQL tech, containerization and data processing platforms along with their custom query DSLs. Other languages like Haskell saw success in small companies and skunkworks style teams solving very difficult problems.

The Rise of Vulnerability Scanning

Just this past year I’ve come to see we’re in the middle of a massive change across the industry. There are new forces at play which will calcify current software stacks and make it extremely hard for existing or new entrants to see similar success without a massive coordinated push backed by big enterprise companies. This force is the rise of InfoSec and vulnerability detection tooling.

Tools like Blackduck, WhiteSource, Checkmarx, Veracode are exploding in popularity, there are too many to list and many variations on the same theme. In the wake of so many data leaks and hacking events enterprises no longer trust their developers and SREs to take care of security, and so protocols are being implemented top down. This isn’t just on the code scanning side, there is a similar set of things going on with network scanning as well which impacts programming languages less, but similarly will calcify server stacks.

These tools are quickly making their way into SOC2 and SDLC policies across industry, and if your language or new infrastructure tool isn’t supported by them there’s little chance you will get the previously already tenuous approval to use them. This sets the already high bar for adoption much higher. As you might expect, vendors will only implement support for languages that meet some threshold for profitability of their tools. Not only do you need to build a modern set of tools for your language to compete, now you also need support from external vendors.

Vendor Due Diligence

Maybe we just cede this territory to enterprise tools with big backers like Microsoft and Oracle, we never more than a few small inroads anyway. The use of these tools is arguably a good thing overall for software security. Unfortunately, the problem cannot be sidestepped so easily, and I’m afraid this is where things look very bleak. The biggest new trend is in enforcement of these tools through Vendor Due Diligence.

You may not be familiar with Vendor Due Diligence if you aren’t in a manager role. The basic idea is your customer will send you a long list of technical questions about your product which you must fill out to their satisfaction before they buy your product or service. In the B2B space where I work these lists are nothing new, but have been getting longer and longer over the last 10 years, now often numbering in the hundreds of questions.

Most recently I’ve seen more and more invasive questions being asked, some even going into how teams are organized, but important to this article is that across the board they now all ask about vulnerability scanning and now often request specific outputs for well-known vulnerability scanning tools. The implication being that if you’re not scanning with these tools they won’t buy your software, and the list of supported languages is small.

Any experienced technology manager sees the natural tradeoff here. When it comes down to making money versus using cool tech, cool tech will lose every time. You’re just burning money if you’re building cool things with cool tech if you know no one will buy it.

So What Now?

Potentially we will see a resurgence of “compile-to” functional programming with mainstream language targets to sidestep the issue. I suppose though that the extra build complexity and problems debugging will prevent this from ever being mainstream, not to mention that the vulnerability tools look for specific patterns and likely won’t behave well on generated code.

There is some hope in the form of projects like SonarCube which enables users to come together and build custom plugins. Will functional programming communities come together to build and maintain such boring tech? I somewhat doubt it. This kind of work is not what most programmers would choose to do in their off time. Similarly, vulnerability detection is unlikely to be a good target to be advanced a little at a time with academic papers. It would take true functional programming fanatics to build companies or tools dedicated to the cause. If you are interested in helping out, pay attention to the OWASP Top 10 as this list drives focus for many infosec teams.

Where does this leave us? If our communities do nothing then smaller B2B software operations focused mom and pop shops or consumer focused web applications likely won’t see any impact unless static analysis makes it into data protection law. Beyond these use cases FP will be relegated to tiny boxes on the back end where vulnerabilities are much less of a concern and the mathematical skills of functional programmers can bring extreme amounts of value.

I know there are many deeper facets I didn’t cover here, if you want to continue the discussion join the thread on twitter.