Our mission is to help the world’s developers build software, safely. We have a lot of areas that we will be tackling and a lot of features we will be building but we started the journey by helping developers know what third-party code they are using, what it does and what components have vulnerabilities first because we think it is one of the most pressing security problems facing software development today. This post is about how we track and identify vulnerabilities and the information we are putting in the advisories.
My colleague Sean Kinzer recently wrote two excellent posts Using CPEs for Open-Source vulnerabilities? Think Again and Why Relying On the NVD is Not Good For Open-Source Security Tools. I recommend reading those posts if you haven’t already.
Hello world. Mark Curphey here. Today we announced a $10 million Series A investment in SourceClear led by Index Ventures with participation from Storm Ventures. Our amazing team is firing on all cylinders (and I’m glowing) on the number of awesome updates and resources that we are releasing in the coming months. I’m here to tell you why on earth we’re doing this.
Every single team we talk to uses third-party code. It is mainly open-source of course and in fact we are yet to meet a single company whose entire business doesn’t now rely on open-source in their core products or services. It’s the new world we all live in and we live in it too. We build everything on open-source and we love it but when we ask other developers to tell us exactly what third-party code they use we are yet to meet a single team that can confidently tell us exactly what. Some have rough idea but when we actually show them they always concede that is was a just a “rough idea”. In the realm of security a rough idea is not good enough.
As a Customer Success Engineer, I spend a lot of time doing product demos and helping with configurations/customizations. I often get asked in demos something along the lines of “I was trying tool ‘x’ or tool ‘y’ which uses CPE’s and the NVD. What do you think of that?”. The other day I was asked the same question over email and so thought I would share my reply (edited for this blog of course). This blog post is about why you should think again if you are relying on CPE’s for open-source software security.
This is part one of a two-part post aimed at a set of people in the security industry that should be self-evident. Part one is negative—”How not to…“—and part two the positive—”How to…” I am writing this because I’m often asked why I have an affinity with developers and engage them in meaningful conversations about security when, as I am told, their eyes usually glaze over in the same conversation with security folks.
“What’s your secret Mark?”
Developers typically depend on a wide variety of open source tools for getting their work done. Every single step in a developer’s modern toolchain touches on one of the many open source tools, all the way from IDEs (Eclipse, IntelliJ Community Edition etc.), compilers (GCC, LLVM etc.), build systems (Maven, Gradle, ANT etc.) to popular 3rd party libraries and components (HTTPClient, Guava, CommonsIO etc.). At SRC:CLR, since the beginning, we have been operating in a polyglot world. Here are 7 of my favorite Java, Ruby and JS tools I’ve used over the past year:
Last week Palo Alto Networks released details of XcodeGhost (first here, then updated here and here). As the story unfolds, other forensic firms like FireEye are now reporting as many as 4,000 apps in the Apple App Store being infected.
In case you have been living under a rock, the attack pattern was simple yet effective:
Boom, boom, game over…
Caching prematurely causes complexity yet when it’s overdue you immediately feel the pain as your app grinds to a halt. You can of course dedicate an entire infrastructure to caching but what about quick-win tactics? Caching provides immediate value to developers, even within a single application instance. A few scenarios where I always try to implement it are:
The goal for this kata is to learn an unfamiliar data structure. It’s called a bloom filter. I’ve read the Wikipedia article and have used them, but until I’ve made it myself I don’t understand it deeply. The more fundamental my understanding, the more flexible I can be in applying a concept. It’s just like calculus. There’s a world of difference between merely memorizing a formula and having a deep, intuitive understanding.
Web sites and other distributed, multi-user systems present unique challenges for concurrent access to shared state. In this post we’ll take a look at a simple strategy (with one big gotcha) for achieving distributed resource synchronization in the Spring JPA environment.