Industrial haskell users - what kind of security workflows do you have

#1

Hi! First of all, I want to disclose that I am asking this not for my personal interest but because I need it for work.

We have an extensive Haskell code base and we have a security team that is disappointed about not having the tools that it usually has at their disposal with regards to e.g. SAST, etc.

I was personally also wondering what people do for audits that are not application specific, e.g. in cardano auditors are usually both cardano and Haskell experts, but if you’re just getting audited for some general code security, the auditors might have problems simply because they don’t know and understand the language and its best practices - Of course this also applies for other (more exotic) languages, but you get the point.

My question is now - do any of the industrial Haskell users have similar problems? I was thinking to e.g. create hlint rules for typical security smells etc.

Then we of course can also use the Haskell security advisories database which we happily use but at least from a security teams’ point of view, it doesn’t replace extensive security linting.

If you’re tempted with pulling out the “I don’t participate in security theatre” club, please don’t, you’re free not to, but in industrial settings you rarely have a choice.

Thanks in advance for any answers!

20 Likes
#2

At my previous position, pulls required 2 approval reviews of senior devs and that was it.

#3

I can’t think what “security smell” one might want to lint for even? Perhaps there are specific libraries with functions prone to injection attacks, and those could be caught. One practice I’ve had before – more for stability than security, but arguably a bit of both – is to enforce either a “safe prelude” with no partial functions, or that all files import prelude hiding the partial functions. You could also ban imports of “internal” or memory unsafe libraries or functions, low level FFI primitives, unsafePerformIO, etc – anything that might open the way to a traditional memory-unsafety attack. In fact, it could be nightmarish in practice, given how somewhat bitrotted the system is, but you could try to enforce the use of “safe haskell” directly as much as possible even!

I do imagine automated tooling around the security advisory database might be nice and somewhat satisfactory to others.

2 Likes
#4

While I can’t contribute anything Haskell related, it might be interesting for some to see what kind of checks bandit runs by default: Test Plugins — Bandit documentation

I’m my view, these told provide a somewhat think layer of security but they’re also cheap to run usually. And it’s a ticked box when ticked boxes are needed.