Clojurians Log v2

Hello, long time listener and first time caller poster here … Can we demonstrate that projects built with Clojure and ClojureScript are secure? I’d love to hear an episode or two, conference talks, and more about that. I’ve been a Clojure(Script) developer for a year now, and I’ve recently started wearing a “security” hat. Underlying the day-to-day work, that’s the underlying question that we struggle with — can we demonstrate our product is secure? What are our options so we don’t have to switch back to Java and JavaScript? It’s pretty clear that customer demand for secure software is increasing. They want to be sure that our code and any of our dependencies is secure, but our language choice doesn’t make it it as easy for them. If the large off-the-shelf static analysis tools and CVE/CWE scanning tools don’t support Clojure and ClojureScript, how have folks in the community solved this problem? With warm regards from Canada and a sincere concern that we’re going to be programming “with some other shit” soon, Sean 🤓

It's a good topic and one that does come up regularly. Large static analysis and CVE scanning tools do support Clojure (I know less about the ClojureScript side but certainly no conceptual reason that couldn't be done). Things like https://github.com/rm-hull/lein-nvd or Sonar plugins like https://github.com/fsantiag/sonar-clojure

Yea, the ClojureScript part seems to be the blocker.

(Hello and thanks again Alex! 😁)

I don't think there's any good reason for that except maybe someone plugging the right bits together

From a general perspective, the problem is not different than the problems faced in Java/JavaScript - the top OWASP issues are the same and the solutions are similar. https://www.youtube.com/watch?v=lRHPZXKQVLk is a good talk on this

The dependency analysis seems to be all about plugging in the right things. We seem to be missing the static analysis rules like sprintf is insecure. There’s 597 rules for Java from SonarSource and 0 for Clojure: https://rules.sonarsource.com/java/

but, does it really matter how the code is written in cljs? It will, in the end, be translated to JS. That is the thing that should be checked. If the JS has a problem, then one needs to figure out whether it is a problem of the compiler or the original cljs code.

for the check though, you would be checking the thing that actually runs on the target platform (JS on the browser). checking for a thing before it is translated, even if it is correct, does not guarantee that it will be correct after it is translated.

Right, we can extend the same argument for Clojure and Java as well. For both cases, I’d expect there are some folks who have lived through this to have some insight on “is it worth the cost to the business to identify the causes of any problems without better tooling?“. I’m very curious if folks have experience with this and if they’d do it all over again.

The other issue that has been raised is that since it is a smaller language, there has been less attention from security researchers. Folks have implied that there are vulnerabilities but they haven’t been found because there aren’t as many eyes on it. I’d expect this issue may need to be addressed in a banking/higher-risk context.

You cannot apply the same argument. clj is not translated to Java, but compiled to Java byte code directly. If that is not true, please correct me.

Oops. I’m about a year into ClojureScript/Clojure and unfamiliar with the Clojure specifics, so sorry the confusion. You are correct. Here’s the authoritative source - https://clojure.org/reference/compilation: > Clojure compiles all code you load on-the-fly into JVM bytecode

I think there is definitely room for automated analysis of user values but a lot of that stuff may require program-specific analysis. I'm not sure how generic the issues are. Some issues around things like CORS or whatever are typically addressed at the ring middleware level and are now automatically included in the default stacks.

I think there are 597 Java rules (https://rules.sonarsource.com/java) but a lot of those are probably related to libraries that most Clojure devs never touch. And on the other hand, there are lots that look for specific Java interop calls that could be pretty easily checked in the same way via automated analysis.

User input is a great example. We may not have the safety net of off-the-shelf tools to do the equivalent of SQL injection attacks since we may not reach for SQL.

I'd say most Clojure users use Clojure libs with pretty good patterns that avoid sql injection in the first place, but the api (jdbc) is the same and could probably be checked in a similar way.

and then there are Clojure specific things either in libs, or stuff like using clojure.core/read without setting read-eval or using clojure.edn/read

what I'm trying to say is - this a very tractable problem where the person/company with the right motivation could make a lot of rapid headway

Absolutely. That’s why I think it’d be curious to see if folks “in industry” have solved this already. There’s a pretty clear path forward if the business thinks Clojure/ClojureScript is essential to delivering the business value. You can justify the extra work and interim risk.

I've had this same conversation like 10 times with different people so I think folks "in industry" have not solvedi t

Over what kind of time period?

last 5 years

Sorry I didn’t find those before broadcasting out to the world. 😓

mostly private

The other change in the business environment over that time period is GDPR coming in. For a large enough company, there is a strong financial motivation to reduce the risk of a breach: The fines for a serious infringement: > could result in a fine of up to €20 million, or 4% of the firm’s worldwide annual revenue from the preceding financial year, whichever amount is higher https://gdpr.eu/fines/

The fines up to 2% or 4% of the firms worldwide annual revenue was etched into us during security training. Can we demonstrate that the team is that confident in their code and choices of dependencies? 💰

GDPR is mostly about informed consent to the capture and storage of private data rather than programming concerns

The environment vulnerability in Bash was exploited successfully, as was the SSH memory leak. Java was mostly removed from browsers and even OSX due to legitimate security concerns. If people think that static analysis will save them they are woefully wrong. There is a tools industry that engenders these fears and must be resisted. It kills deployment automation, costs stupid money and offers nothing compared to teams keeping their libraries and skills up to date.

> give me your money and my AVS (awesome vulnerability scanner™) will keep you s3cure. > -- John Clickbait clojure emphasises on simplicity through thoughtful design and by blindly putting trust to such tools could cross the line where it is contradicting the design process. on the other hand I can see how non-technical people like reports that "make sure" that things will be fine.

there are plenty of things that could be usefully checked and automated

and also I'm always in favor of using your brain

Ray’s comment hits home: > There is a tools industry that engenders these fears and must be resisted. It sounds like there’s a trend towards more customers having a checkbox on a product acceptance form like “have all third-party dependencies have been scanned for CVEs and CWEs and included in the report?“.

I agree, and to be clear on what I said above, I mentioned that there's a line that may be crossed. In other words a balance is at need. I am not against linters or compiler warnings or SonarQube .. but at the same time I recognize that I need to understand, think, design and experiment with the domain I am involved. I think it was mentioned above - the tools do not guarantee security, the same way that tests cannot guarantee bugfree programs; what they do is increase confidence that basic security measures are in place, and things will work. We should all keep in mind that automation has its own pitfalls and paradoxes; it is not a solution for everything.

I’ve been coding long enough to know I trust my brain not to write secure code. 😆 We’re trying to assert that we’ve also checked the CVEs and CWEs found by those security researchers we should trust (or strong minded folks who know better).

Have other folks run into that? Sounds like Ivan can make a tidy sum selling AVS.