Every so often, I get together with a group of friends to have a barbecue, watch a game, or grab dinner. We often talk of our work and careers; one friend engineers aircraft engines, another manages logistics at an eCommerce company, and another is in healthcare. And although we all have a different set of professional experiences and punch our cards in a variety of industries, there is one thing we all have in common: We all work for software companies.
Now that the age of digital transformation has run its course, a company need not have software in its portfolio of products to be a software company. Plenty of organizations across every industry rely on applications to enable their business, reach their customers, and run their day-to-day operations. More often than not, these companies develop a considerable portion of these applications in-house. Think about the websites you use to order your household needs online, or the mobile application you use to deposit checks to your bank account. This isn’t software that the eCommerce company or the bank sell, but it certainly plays a crucial role in how they do business.
Being a software company comes with additional responsibilities, though. Just as a traditional software company does, these organizations must dedicate a good deal of effort to maintaining and securing the applications they build and operate. However, given the complex makeup and delivery of this software, this is no easy feat.
Different parts of the tech stack will most likely be built by different teams, each using various languages and frameworks, and each consisting of a combination of proprietary and third-party or open source code. Most likely, the resulting application will be chopped up into microservices, containerized and deployed onto servers not owned by the company, and made accessible to consumers via an array of APIs.
This all makes for an extremely broad attack surface. Mitigating the risk associated with complex applications such as these requires securing every component at every stage of the life cycle. As such, an increasing number of organizations have adopted software supply chain risk management programs to obtain maximum visibility and control of the software they consume, build, and operate. But what makes a program like this effective?
The 2022 “Critical Capabilities for Application Security Testing” (AST) report by Gartner details the necessary tools and processes for securing enterprise applications. By implementing these critical capabilities in a complementary manner, organizations will find themselves best equipped to address risk introduced at every node of their software supply chain.
The first, and most critical, capability is securing external dependencies, such as open source and third-party code. By definition, these dependencies were developed by someone else, using practices and tools outside the control of your company. It’s crucial to identify these dependencies in your codebases, maintain a dynamic inventory of them, and use it to track related vulnerabilities and license obligations. The only way to do this effectively and efficiently is with a software composition analysis (SCA) tool.
External code is not your only concern. You can patch every open source vulnerability the day it’s disclosed (if that’s even possible), but if your developers aren’t coding securely, your efforts are futile. However, the security weaknesses introduced by developers can be rather complex and difficult to spot in code review, even by a trained eye. Static application security testing (SAST) analyzes applications to spot potential vulnerabilities automatically, which is why it’s considered one of the most critical capabilities.
If you think handing engineers AST tools designed for the security team is the answer though, I have bad news for you. To truly make developers the first line of defense in securing your supply chain, it’s critical to integrate open source governance into developer tools and workflows. Developer enablement tools such as IDE plugins, actionable risk feedback, and education and training aid in the efforts to shift security left.
And integrations shouldn’t stop at the development phase. APIs and plugins to version control systems, build systems, deployment tools, and ticketing tools are some of the life cycle integrations necessary to seamlessly integrate application security testing into the entire software development life cycle.
Although Gartner details additional capabilities, the four listed above make up over half of the criticality weights assigned in the report.
At Black Duck, we’re proud to offer solutions that fulfill every critical capability detailed by Gartner, and also to have received the highest score in the Enterprise AST use case, compared to 13 other AST vendors.
Black Duck® SCA enables our customers to secure and comply with the licenses of any external code they depend on, and Coverity® SAST ensures that their developers are coding securely without the need for tedious, manual code review. Both products offer comprehensive dashboards and user interfaces, and also enable developers to take charge in the security battle by offering SCA, SAST, and infrastructure-as-code (IaC) scanning from directly within the Code Sight™ IDE plugin.
Additionally, Black Duck offers solutions that our customers use to analyze the contents of compiled code and containers, and test running applications and APIs. With Black Duck, you have the ability the inject security into every stage of the application development life cycle, so you can trust the integrity of the applications running your business.
As is usually the case in application security, there is no “one size fits all” approach. Your business will have unique needs, workflows, and risk tolerance.