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? - 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. 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 --- 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.
