##CONTINUE##
In reality, we think that development is moving, at the behest of its paymasters in the business, towards "holistic service delivery"—and "holistic" means that application integrity and resilience should be designed in from the first. An automated service should do exactly what the business needs, no more and no less—and, presumably, the business doesn't need services that can be taken over by criminals and used to divert company resources into their pockets. Controls to prevent dysfunctional behaviour should be designed in—the security professionals should probably be advising on what is needed, not bolting on security technology after the application is built (as Microsoft found out when it tried to make earlier versions of Windows more secure).
So we were interested to hear of the latest offerings from Coverity, which started off as an application security company with static and dynamic analysis tools. Although it is still somewhat code-oriented, according to from Thomas Schultz (Principal Product Strategist) it is now offering to help with Application Integrity in a more general sense with its Architecture Analyser and even has a "software readyness" dashboard which can help to inculcate "comfort" with application governance for business stakeholders in automated services. Coverity is beginning to offer more than just a security "point product". It now recognises more stakeholders in "application integrity" and more opportunities to educate them in good practice.
However, it offers a (usefully) disruptive technology with implications for company culture—introducing integrity early and often helps break blame cultures—so introducing it will require informed business sponsorship from the very top as as well as buy-in from developers at the sharp end. This isn't always easy to achieve but a period of "hard times" is when the real waste associated with lack of quality and integrity failures can't be tolerated, so Coverity sees the recession as a new opportunity for "doing it right" in many companies—and hopes to be part of this.
Coverity's tools hook into code at compile time and help you to discover "not the architectural design you think you have is but what it is 'as built'" and they can export information to upper level (business process) tools and BI suites. They recognise good practice "patterns" for the use of development frameworks and notify divergences from them—so that good practice can be enforced. They codify architectural rules for legacy applications and enforce them too—80% of the application lifecycle is in maintenance, so it's important that "application integrity" doesn't degrade with maintenance.
We found Coverity's approach, and its focus on the bigger picture around its technology, refreshing, so we talked further with its CTO Ben Chelf about some "blue sky" futures, starting with the history of Agitar, which we thought had an interesting story in the Unit testing space (see this article). Agitar now belongs to McCabe. According to Chelf, Agitar's problem (aside from its Java focus; few holistic business services will be written wholly in Java), was that Agitar's technology was essentially an implemented research project. Automated unit testing is a very good fit with eXtreme Programming and the Agitar technology is very clever, but it was difficult to classify the mass of unit test data in a way that conveyed "quality" (as opposed to completeness of coverage) to the business. Perhaps Coverity has technologies that could have helped with this; however, it doesn't own the Agitar IP. Nevertheless, Danny McLaughlin, Coverity's new Director of European sales, comes from Agitar and Chelf says that several Agitar technicians came to Coverity, so perhaps there is hope there for implementing what Agitar didn't do....
Chelf thinks that Coverity's "Application Integrity" approach is complementary to the offerings from conventional ALM (Application Lifecycle Management) vendors, although we wouldn't be surprised if the competition is working in this area for "ALM 2.0" too. However, Coverity looks like it will be early to market with a well-thought-through offering—and working back from security testing is a nice idea. We hope that Coverity doesn't get its products "siloised", by its customers, just for security people or even just for developers. They should be interesting to a much wider community.
In conclusion, traditional application developers are facing several life-changing issues. To start with, the essential complexity of loosely coupled, asynchronous, applications is increasing. If you can't exhaustively test more than about 16 lines of code containing an IF statement or two, what hopes of testing a set of interacting services, some of which come from outside the organisation and you have no control over? Some form of test automation and identification of dysfunctional "antipatterns" of technology usage would seem to be essential. At the very least, it must be possibly to separate "essential complexity" (some problems are inherently difficult) from avoidable complexity introduced by poor design and/or maintenance decisions—and make sure avoidable complexity is controlled.
Then again, the gap between business objectives and business benefit and what the code actually does must be bridged. As times get hard, it seems sensible that automated systems should do exactly what the business needs to do in order to make money, neither more nor less (and automation that facilitates, say, fraud or annoys customers with clumsy security procedures, would seem like a pretty bad idea). But translating between "customer delight" and relational normalisation of a computer data store isn't exactly obvious. Automation can provide assistance for maintaining the many-to-many links between "business outcomes" and detailed technical decisions at the code level—although (outside, perhaps, of a purist Model Driven Architecture (see this site) there will always be a human component of this.
However, perhaps an even bigger issue is that businesses are no longer prepared to be handed "applications" which they have to put lots of work into before they are any use to the business. In fact, businesses have never been happy with this but (as increasing numbers of business managers have had IT as part of their education), businesses have now become prepared to call IT's bluff on this one. It's not just building in security—it's also also application reliability/resilience (perhaps "business continuity" should be built in too). Automation (using both dynamic and static analysis of the actual code) can help developers develop better and more efficiently, by providing immediate feedback when "good practice" is departed from. Moreover, similar techniques to those used for code analysis can be used to analyse models for shortcoming—nothing is more fatal to developing good (in the widest sense) code than a business process that is incompletely specified, inconsistent across the organisation or just plain wrong.
We think that Coverity is showing all the signs of helping to address these issues and may be further down the path than many of its competitors, although it isn't the only company thinking along these lines (even Microsoft is now talking about radically different approaches to application integrity (a.k.a. testing); see here.
BY David Norfolk, Practice Leader - Development, Bloor Research
Source：IT-Director.com
Posts
0 comments:
Post a Comment