Tag: code hygiene

  • Flexera Extends Scope of Open Source Scanning Tools

    Flexera Extends Scope of Open Source Scanning Tools

    Now that many IT organizations have adopted an open source-first mentality to acquiring new software, tracking their dependency on all the various modules they are employing is becoming more challenging with each passing day. To help IT organizations track both usage and dependencies of open source software, Flexera has updated the FlexNet Code Insight software to continuously scan the network for open source software and highlight any known security and compliance issues.

    Based on code Flexera gained when it acquired Palamida in 2016, FlexNet Code Insight is now easy to navigate using a single dashboard, says Jeff Luszcz, vice president of product management at Flexera. Its capabilities span high-level package analysis to more detailed analysis that detects when snippets of open source code are being used within a third-party application regardless of build dependencies, sub components, source code, modified source code and binaries and even Docker containers being used.

    In addition, this release of FlexNet Code extends the integration Flexera provides to continuous integration servers and third-party build tools to automate scans during the software development process. IT organizations also can create their own custom plug-ins, says Luszcz.

    FlexNet Code Insight can identify 13 million open source components and supports more than 70 extensions. That includes integration with data from the National Vulnerability Database and security vulnerability assessment software developed by Secunia Research, which Flexera acquired in 2015.

    Luszcz says FlexNet Code Insight is a natural complement to the tools Flexera already provides for tracking use and dependencies between instances of commercial software. The difference now is a steady increase in the rate enterprise IT organizations are now depending on open source code, which changes more rapidly.

    Flexera is not the only vendor these days focusing on identifying open source software (OSS) vulnerabilities and associated compliance issues. But it does uniquely provide tools spanning both commercial and open source software. That capability is especially appealing to senior IT executives who would prefer to rely on a single vendor to provide both classes of tools, says Luszcz.

    While there’s currently a lot of enthusiasm for open source software in the enterprise, Luszcz says many IT leaders don’t appreciate some of challenges that lie ahead. Most open source software is made up of modules provided by different developers working within the confines of an open source project. Updates to that software to address, for example, a security flaw are not easily propagated throughout the ecosystem. In fact, Luszcz says that very issue lies at the heart of recent security breaches that occurred at Equifax.

    Having a local repository to keep track of what software is being used simply isn’t enough, Luszcz says. IT organizations need an end-to-end approach for monitoring all the updates made to that software regardless of where it originates.

    Of course, when it comes to open source software there really is no going back. Lusczs notes that as far as compliance and security are concerned, the proverbial genie is already out of the bottle. The only question now is how to marry OSS tools to DevOps processes to make living with that open source genie a lot easier for all concerned.

    — Mike Vizard

  • 5 DevOps Techniques to Improve Software Hygiene

    5 DevOps Techniques to Improve Software Hygiene

    Thinking about frequent food contamination outbreaks, perhaps the old adage, “You are what you eat,” should be modified to, “You are what you eat—as assembled across an unknown supply chain.” Even foods advertised as fresh and healthy can be quite the opposite. And it could be because of just a single unhygienic practice hidden within the food production life cycle.

    It’s not unlike the issues facing modern software development. Now with the advent of open-source, cloud computing and component-based designs, the succulent software morsels we deliver can be fouled by a range of contaminates. And while not as a physically debilitating as a case of gastric flu, the impact on business can be extremely severe, such as major security incidents and compliance breaches—the E. coli of digital software production.

    The good news is that IT organizations can take effective steps to mitigate the risks. Much like food processing, software contaminates can be introduced anywhere code and data is handled and stored—from requirements and coding to testing, release and operations. This means all stakeholders must take responsibility and be held accountable for software quality. To that end, here are five good practices DevOps practitioners can use to improve software hygiene:

    Thoroughly wash test data before handling – Creating, maintaining and provisioning accurate test data is one of the most time-consuming and resource-intensive challenges in continuous delivery. It’s also fraught with business health hazards if teams fail to protect personally identifiable information or continually rely on data that’s well past its use-by date. With public cloud services providing convenient platforms for testing, ignoring these issues will only increase the risk of major compliance breaches. It’s important, therefore, to supplement data migration with fully automated methods to mask and subset sensitive data. Additionally, by continually enriching virtualized or emulated services with realistic test data, teams have a repeatable method for improving the quality and efficiency of testing.

    Pay special attention to open source freshness – Open-source software has become a large contributor to the portfolios of many organizations. But just because something is “free” doesn’t negate an organization’s responsibility for due diligence, including understanding total cost of ownership and mitigating security risks. Even though open-source projects have active communities, that hasn’t stopped code pathogens lying dormant for years (for example, Heartbleed went unnoticed for 2.5 years).  With open source, the onus is on development to retain code “freshness”—something that might be difficult if teams are constantly being pulled onto different projects, or if thorough risk control management isn’t a core competency.

    Don’t leave software lying around for too long – Just as many foods spoil quickly, software release bottlenecks can quickly leave a sour taste for business. Like a truffle imbues a marvelous aroma, modern digital business must be flavored with a continuous stream of application updates. And, since windows of business opportunity close quickly and application lifespans are as short as days, it’s critical any deployment delays are removed. Letting software linger in the release queue also introduces other hygiene issues—for example, teams putting off documentation or code-refactoring because they know they can always get back to it later. Inevitably they never do, and when the code finally gets deployed it’s unclean or laden with defects and bugs.

    Set up a “health inspection” SWAT team – In the traditional “software factory,” application performance management, security auditing and compliance checking often comes late in the software development cycle—leading to delays and conflict. DevOps, with its focus on team collaboration and continuous feedback, aims to rectify this by embedding these practices much earlier. But when resources are limited, it’s not practical to assign a security or operations professional to every agile team; it just won’t scale. What’s key, therefore, is to take a more pragmatic approach; developing teams of specialists and repeatable automated practices others can leverage to remove “bad smells” from code. This could involve:

    • Regular education on web application cross-contamination issues and modern API security techniques
    • Moving application performance management into pre-production to improve quality
    • Auditing services to regularly check composite applications assembled from third parties and open-source software
    • Automatically invoking application security testing before and after release and deployment
    • Methods to automate testing as requirements are modeled and changed—immediately linked to correct data and expected results
    • Scoring mechanisms to highlight security and risk problem areas—all bubbling up to a team and divisional level

    Work with your suppliers – In the rush to embrace modern cloud architectures for application scale and resilience, teams often forget that even the most robust platforms can succumb to problems. Savvy teams understand this, working with their cloud partners using modern monitoring and analytical methods to quickly detect and respond to many complex issues well beyond the scope of traditional rules-based methods and slioed tools. By using a design-for-failure approach, DevOps teams understand that no platform is infallible, preferring instead techniques that quickly anticipate and contain inevitable failures to keep the digital business running.

    Even the tastiest of food can be toxic, and it’s the same with software. However functionally rich our software creations appear to be, contaminates lurk everywhere within the software pipeline. Use DevOps techniques to pinpoint and eradicate “digital spoilage” quickly, and avoid making the business and customers ill.

  • How To Maintain Open Source Code Hygiene

    How To Maintain Open Source Code Hygiene

    To maintain good open source code hygiene in the development process, you must first establish what you mean by open source code hygiene, including good and bad hygiene. “By hygiene, we just mean is it appropriate? Is it clean for the intended use?” says Mike Pittenger, VP of Strategy at Black Duck Software.

    Black Duck suggests three metrics it uses to determine whether it is appropriate to apply a given open source code project to a certain development endeavor:

    • For software that will be distributed at large, avoid open source code that the development community has made available through a GPL license.
    • For secure software, check your potential open source code for vulnerabilities in general and make sure to use the most secure version available.
    • Monitor the code periodically to check for new vulnerabilities or other concerns.

    As an example of the third point, Pittenger notes OpenSSL is no longer a viable option because of the vulnerabilities that have come to light in the form of Heartbleed.

    Checking Source Code for Open Source Concerns

    While the InfoSec Institute recommends at least 14 different open source vulnerability scanners for web applications alone, offerings such as Black Duck’s can serve as a shortcut to discovery of known bad open source components. “Instead of having to load Nessus, Metasploit or Nexpose with a Heartbleed rule and scanning every application, every server that they’ve got, they can just go into their Black Duck console, type in OpenSSL, and it would immediately show them every version they used in their software applications,” says Pittenger. Of course, you should always do your own due diligence to determine whether any scanning product is the best choice for your organization and aligns with your needs and requirements.

    Due to the many open source code reuse scenarios active in enterprise DevOps shops, you will want to continually monitor code for newly registered vulnerabilities. Enterprises can view reusing existing assets as a built-in savings by not having to purchase or create new assets. In the case of reusing legacy source code, there is also a time savings, as developers want to shrink time to market for code-based projects.

    “Let’s say you have a company that is pulling information from a database to display in pie charts. You have a rendering component that you will reuse. When you’re starting on a new product, do you build a new rendering library from scratch or do you use the existing one?” asks Pittenger.

    Even if those components are open source, there can be great savings in reusing the library.

    The fact that enterprises do this underlines the importance of continuing to check any code that leverages open source code, as this is how vulnerabilities can spread over time. It’s also important to check open source code, because it may be a form of low-hanging fruit for attackers. Open source code is fully viewable by attackers who build malware and launch attacks, whereas proprietary code is closed.

    Since people constantly discover new vulnerabilities in open source code components that previously had tested free of such holes, it’s important to monitor those components for newly uncovered weaknesses, even as you reuse open software in new projects.

    Containers are a great example. You may want to dismantle an image in varying degrees to build a new application. “If I have a base image and it’s built using a LAMP stack (i.e., a Linux OS, an Apache HTTP server, a MySQL RDBMS and PHP), I can strip down my base image, take away the existing app and take it all the way down to the Linux component, then build it up for the new application,” Pittenger said. “That is a typical, consistent reuse of open source components.”

    During the process, recheck every component for vulnerabilities. Even if everything checks out doesn’t mean you have the best assurance of security for those components going forward. By monitoring those components, you can stay on top of updates to fix any newly discovered security holes.