|
|
AS OF 7/4/2008 8:27PM EST
|
July 15, 2007 —
First came the announcement last month that IBM would acquire Watchfire, which sells security assessment software. Then HP followed by announcing it would buy SPI Dynamics, another well-regarded software security company.
Industry pundits had been writing for some time that there would be consolidation in this market, which features companies such as Cenzic, Klocwork and Ounce Labs. Any or all of these concerns could be ripe for the picking by Microsoft or Oracle, which as of now do not offer a secure software solution to compete against IBM and HP.
These acquisitions are a signal that software tool providers acknowledge that firewalls, access control lists and other measures are not enough to stop the siege from hackers looking to exploit personal data or to simply lock up a system for the fun of it. These major companies are learning that security is something that needs to be addressed during the creation of code, not a feature to be slapped on at the end.
Preventing access only stops people from getting to your data in ways you expect; writing secure code can cover the entry points you don’t immediately think of, or even see.
IBM already had tight integration with Watchfire in its Rational development life-cycle tools, while HP will incorporate the SPI Dynamics functionality into its former Mercury testing and QA tools. That’s an excellent first step toward securing software, in addition to securing networks and servers.
The harder challenge remains: convincing the people who gather requirements, create models and write code that security is their responsibility as well. Analysts have cited an unchanging culture among developers as a roadblock to security. And vendors have said you can give developers all the tools in the world, but you can’t make them use them.
Well, their bosses can. Now that IBM and HP are providing enterprise-class tools for security assessment, it falls to the development managers and project managers to make sure security is considered at each step—requirements, modeling, code, build, test and QA. They have a harder job than the vendors, but software will always be vulnerable until they get buy-in all along the life cycle.
Purity Isn’t Always Practical
Ideological purity is a wonderful thing, when one is on the side of the angels. Unfortunately, most of us exist in a more workaday world and have learned that ideology doesn’t necessarily make for sound business decisions.
Not everyone agrees with that, of course, as vocal members of the open source community view the world in black-and-white terms. Consider the fuss being raised by some members of the open source community over Microsoft’s ongoing series of deals with Linux distributors. When Novell came to terms with Microsoft last fall, we noted that it looked like the 1939 Molotov-Ribbentrop pact all over again. At the risk of overextending the analogy, Microsoft’s deals with Linspire and Xandros look more like pacts with Horthy-era Hungary and Mannerheim’s Finland. In other words, the users affected are an infinitesimal slice of the pie.
It is clear that Microsoft’s leaders feel threatened by open source technologies. But even the company’s most ideologically committed executives and managers recognize that the cat is out of the bag, and Microsoft is now willing to work with the open source community, whose money is just as green as anyone else’s. Microsoft is cutting deals with companies because it’s used to dealing with businesses, not amorphous communities.
But, as cynical and jaded as we are, we don’t see a downside from these arrangements affecting end users, or the open source community as a whole. Like it or not, Windows interoperability is a must, and dealing with Microsoft is a must, if Linux is going to continue to grow as a broad business technology.
|