Thanks for the shout Alex. Jason reached out to me directly but I figured it would be better to answer this for the broader group. I’ve got a lot of thoughts around this and I am happy to dive deeper into any of these as well.
On the topic of static analysis, I don’t think that application static analysis is a good fit for Clojure programs. It’s not that it couldn’t be done, it’s that static analysis on a language like Clojure is incredibly complicated and bound to produce a very high number of false positives. As it sits today, static analysis catches between 20-35% of security issues, which really isn’t a great start and certainly doesn’t produce secure software. Producing secure software requires much much more than static analysis. IMHO a company that is looking to produce secure software should be practicing the following: Threat modeling Design and architecture review Data classification Trust modeling Code review (human based and static analysis if applicable) Dependency analysis Dynamic analysis (penetration testing) Infrastructure/Deployment analysis (newer but still incredibly important and now easier on platforms like AWS) including activities like vulnerability and patch management and container analysis Long story short is I put little faith in static analysis. It’s a tool in a long list of practices on the way to producing secure software. I emphasize it much less when working on a Clojure program, but to me that doesn’t make Clojure worse off from a security perspective, it just means that I will double down on some of the other practices. There are so many default traits of Clojure programs that put it ahead of traditional languages that more than make up for the lack of ability to produce clear static analysis. > On Apr 13, 2018, at 9:30 AM, Alex Miller <a...@puredanger.com> wrote: > > > > On Friday, April 13, 2018 at 8:38:51 AM UTC-5, Jason Turner wrote: > Hi Alex, > > Thanks for the rapid feedback. Before anything else I should say that we > loved Clojure before using it at work, and we're even more in love now we are > using it at work - a huge thankyou to the core team and Rich, and a great > community. > > Yes - I did see your previous comment but as was a long time back and I had a > broader context seemed useful to use a new post. I understand your point - > making changes to avoid false positives is frustrating at best. At this point > in time we are analysing to first see to what extent we can 'fix' these, and > then what the picture looks like once they are 'fixed' (given that on top of > these issues there will obviously be both false and real positives > (presumably) in our own codebase (currently just a small prototype system); > so if we find any real issues we will definitely feed back to you thanks. I > think that we will anyway report back to you our findings on the core false > positives - I understand you may not pick them up but seems a good source of > info. > > Wrt the context - you are right there are several banks using Clojure - I > have reached out a bit to get advice or experience, but so far not been able > to find anyone who has had to do this and been successful. I think a key > factor is that many banks operate (not without justification) quite different > policies wrt their own home-build projects and services and products which > they license from third party vendors; so I suspect that the majority of use > is for in house work - e.g. Capital One, Nubank. > > Anyhow I agree this isn't an issue for everyone - ironically and very > frustratingly we are convinced that Clojure is actually facilitating security > over e.g. Java in many many ways. > > For us the real challenge is to find a cost effective (fairly) objective > scalable means of evidencing to our customers that the product has a robust > security design: we are smallish and have a large customer base of large > customers. Sorry to bother you with various questions around this - but > wondering if you may have the experience or contacts to highlight some > alternative avenue: > We are currently using HP Fortify which is not a bad product, but there are > others such as Veracode. To my knowledge they are all broadly similar and > none of them are currently providing anything Clojure friendly - but would > you know of something more Clojure friendly? > Sorry, I'm not aware of any better alternative. > Our current approach is based around this route of using known objective > analysis - for all its shortcomings (it is painful enough in Java). We are > just now pondering to what extent we could solidly demonstrate on a more > 'hammock based' approach i.e. list out long list of vulnerability categories > and cite the design and implementation approaches which mitigate or prevent. > This is in itself useful and an extension of what we anyway do - but customer > wise it is obviously not really 'objective'. A way to make it more strongly > objective would be to use a third party - that may however be costly. > Similarly we are wondering to what extent we could expand the work we do in > terms of ethical hacking / penetration testing - perhaps we could raise the > bar there in terms of automation. > You might want to talk to Aaron Bedra about some of this - he does security > consulting and is deeply knowledgeable about Clojure systems as well (and > spurred a lot of changes in the Clojure web frameworks to default to better > security). > > > > Thanks a gain for your time. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > <http://groups.google.com/group/clojure?hl=en> > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
