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
For more options, visit this group at
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.

Reply via email to