Security Resources for Elm

[rickowens]

Hello Elm community! I am putting together a report to help evaluate the possibility of adopting Elm as part of my company’s tech stack. As part of that, I need to address the security landscape of using Elm.

It is clear to me that the security situation in general is pretty great. In particular with respect to supply chain attacks, it seems like the goal of the Elm community is to make those kinds of attacks more or less impossible at the language level, or at least perhaps relegated to packages providing functions of type Cmd, but I have been unable to find any sort of “executive summary” (which might, for example, explicitly state supply chain security as a sanctioned design goal of the language, rather than just “it seems to be implied based on these blog posts and forum discussions”).

“These blog posts and forum discussions” that I’ve found so far include:

• Security in the Elm ecosystem: Security in the Elm eco system
  This seems to be somewhat outdated though.

• This excellent blog post about having recently fixed a particular security issue: Fixing vulnerabilities in Elm's virtual DOM | jfmengels' blog

• Another fix for some particular vulnerabilities: GitHub issue #56 on the elm/html project.

• A few more conversations in a similar vein as the above, some only tangentially relevant (and which I can’t link to in any case, because Discourse informs me I can only post 2 links because I am a new user ).

Some specific questions I would like to find answers for are:

• Is the prevention of supply chain attacks an explicit design goal of Elm, as it seems to be?
• Is there some higher-level security overview or resource I’m overlooking?
• Is there a database of security advisories for package.elm-lang.org (e.g. like the one recently approved for the Haskell community)?
• Are there any automated tools for security scans?

I would also welcome any other suggestions for either resources I should look at, or approaches to communicating the security landscape to my company, or anything else for that matter!

Thank you!

[wolfadex]

Is the prevention of supply chain attacks an explicit design goal of Elm

I’m not certain, though I’ve never heard this mentioned in any discussions

Is there a database of security advisories for package.elm-lang.org (e.g. like the one recently approved for the Haskell community)?

Not that I’m aware of, though there are a handful of people in the tooling community who periodically clone all packages and run code against them. I’ve not heard from any of them of any security issues.

Are there any automated tools for security scans?

None that I know of, though there are some automated tools that will make PRs to packages for a few elm-reviews. There’s also an RSS feed of package releases which is used to post to #packages in the Slack. All of this to say, if you really needed some automated tooling, you could likely build something based off of these. The RSS feed could notify you of possible dependency updates and elm-review could be used to assist in checking for vulns.

---

I’ll also add, anecdotally, that at Vendr we have ~600k lines of Elm (some generated) and have been using it in production for 7 years. I’ve not yet heard of security being an issue in our frontend.

[jfmengels]

Hi Rick

Happy to hear you liked my blog post

Is the prevention of supply chain attacks an explicit design goal of Elm, as it seems to be?

I don’t know, I don’t think it is. But Elm tries to make code predictable and bug-free, and supply chain attacks come with the territory a bit, I would say. It’s mostly the fact that the language gives you very few low-level primitives that can lead to security issues. If you secure those, then even dependencies with malicious intent will have a very hard time doing anything useful from an attacker’s point of view (a pixel tracker is basically the worst that I can imagine, when we don’t count packages that uses Tasks/Cmds).

Are there any automated tools for security scans?

There isn’t any security advisories, so looking through open issues will probably give you the best results. In practice, there are very few issues. From memory, I think there was a potential issue in elm-explorations/markdown (that I was not able to reproduce). The rest I am not aware of, I forgot, or I helped fix with the latest elm/virtual-dom patch.

Are there any automated tools for security scans?

There isn’t any one on the market, but I have been building such a tool. It’s not finished yet and I had to pause my work on it, but I’d be happy to talk more about it here or in private.

Basically my approach was to use elm-review as a tool to start from known vulnerabilities (which are extremely few as said before) and see how they spread across functions. For example: elm/virtual-dom v1.0.2’s VirtualDom.nodeNS had a vulnerability in specific conditions. Some of elm/html’s functions used this function without changing the conditions for the vulnerability, therefore the vulnerability spreads to them as well and we can look at the functions that use these, and so on.

I think this approach will work quite well, and is a lot simpler and reliable than analysis you can do for JavaScript. It’s still somewhat complex, but it’s very promising.

If anyone is interested in me continuing this work, let me know as that might make me re-prioritize what I feel like working on

---

Same as @wolfadex, we use Elm at CrowdStrike (formerly known as Humio), and security has not been an issue.

[matt.cheely]

elm-explorations/markdown uses quite an old version of the marked library and I would strongly recommend against using it for user-supplied input, but that’s the only security risk I’m aware of. The limited ability to publish packages with Kernel JS code really reduces the surface area you need to audit, which is extremely nice.

[rupert]

@matt.cheely

elm-explorations/markdown uses quite an old version of the marked library and I would strongly recommend against using it for user-supplied input

Never thought of that!

Feels like elm-explorations/markdown should really have a DEPRECATED notice added to its README, and probably also a security WARNING too!