Recently I got a message from Kelley Jackson Higgins of Dark Reading. She was looking for some comments on Fortify Software’s new paper on “Cross Build Injection” or “XBI”. I had read the paper and, while I think the issues are real, the way they are framed they miss the big picture. So I figured I would partake in a little “XPI”, that’s “Cross Publicity Injection”, and take this opportunity to talk about the larger issue of accepting code into the build process. The Dark Reading article is here.
Whenever externally developed code of an uncertain security posture is made part of software, it adds an unknown amount of risk to that software. The external code could be an open source framework or it could be a commercial binary library. This external code needs to be treated as radioactive until proven otherwise. Why take the effort to build your software with a secure design process, threat modeling, and secure coding just to have it all fall apart because of a backdoor or critical vulnerability in a library?
Security testing is a partial solution because when you test you are analyzing the entire program, including the external code, but it typically isn’t good enough. It won’t find backdoors and testing coverage is a perennial problem. A good solution is to use static analysis on the external code before you decide to use it. This way, if it has poor security quality and the vendor won’t fix it you can select another library or framework.
Making security part of the acceptance testing process is gaining support in the financial community, which is often on the leading edge of information security. BITS’s FISAP is being used by financial institutions to evaluate their IT service providers. Veracode has customers who are using our Vendor SecurityReview to evaluate the security quality of COTS products before they purchase them. We now have ISVs who use externally sourced binary libraries and other binary components as part of their applications coming to us to get this code reviewed.
Just because you didn’t write the code doesn’t mean you aren’t responsible for its security quality when you include it in your software. If you have a secure SDL for your developed code, but you aren’t analyzing the external code in your application, you still have unknown risk you are shipping to customers or accepting yourself to run your business.
Think of the big picture of external code. Sure “XBI” is real. It is foolish to automatically pull down code from an external site every time you run your build. But just setting up an internal repository for external code won’t solve the problem. The real solution to external code risk is vetting that code before you use it.
Written by: Chris Wysopal