devopsy.kinsta.cloud

Tag: SAST

  • Checkmarx Brings Generative AI to SAST and IaC Security Tools

    Checkmarx Brings Generative AI to SAST and IaC Security Tools

    Under an early access program, Checkmarx today made available query builder and guided automation tools that take advantage of OpenAI’s generative artificial intelligence (AI) technologies to make it simpler for developers to resolve application security issues.

    AI Guided Remediation surfaces actionable remediation recommendations for vulnerability issues such as misconfigurations directly from within integrated development environments (IDEs).

    Meanwhile, AI Query Builder makes it possible to use natural language text to create a query for both the Checkmarx static application security testing (SAST) and the infrastructure-as-code (IaC) security tool that creates rules for scanning code. Those rules can be easily fine-tuned or modified and queries for other use cases can easily be added.

    In addition to reducing the amount of time it takes to create a query by 65%, that approach also dramatically reduces the number of false positive alerts that arise based on rules created by a security administrator.

    Checkmarx CEO Sandeep Johri said these additions to the Checkmarx One Application Security Platform are aimed at improving the application security experience for developers. Most developers don’t want to be inundated by alerts that lack any real context, nor do they want to be bothered with remediation details.

    It’s not likely developers will be interested in how AI could help them write more secure code from the start, but the faster a reliable fix is surfaced, the sooner developers can return to writing code, noted Johri.

    In the longer term, Checkmarx will add support for multiple large language models (LLMs) beyond those provided by OpenAI to provide other AI capabilities that are based on more domain security knowledge, said Johri.

    However, despite these advances, vulnerability remediation will not become fully automated using AI any time soon, he added. Instead, it will become much simpler to identify code that has either inadvertently or deliberately introduced a vulnerability, said Johri.

    In fact, generative AI tools such as GitHub Copilot can themselves introduce vulnerabilities into code. As a general-purpose AI platform, the recommendations surfaced are based on a mix of instances of clean and flawed code, Johri noted. There will also be instances where cybercriminals attempt to subvert an LLM that creates code by injecting snippets loaded with malware into the samples used to train a generative AI model.

    On the plus side, however, generative AI tools should narrow the divide that currently exists between application developers and cybersecurity teams as more issues are discovered and remediated before applications are deployed in a production environment. The challenge has aways been surfacing application security issues at the time developers are writing code rather than sending them a list of vulnerabilities to address weeks (sometimes even months) after a developer has moved on to another project.

    Naturally, there is a lot of trepidation when it comes to all things generative AI; one area of certainty is that the benefits far outweigh the risks—especially when it comes to developing secure-by-default applications.

  • Mobb Launches Community Edition of Automated Remediation Tool

    Mobb Launches Community Edition of Automated Remediation Tool

    Mobb today made available a free community edition of a namesake tool that creates fixes to open source vulnerabilities. The fixes are based on the results of code scanning by a static application security testing (SAST) tool.

    Fresh from raising $5.4 million in seed funding, Mobb CEO Eitan Worcel said the company developed a tool that creates validated patches based on the scan results of third-party SAST tools from Checkmarx, GitHub and Snyk. Initially, the tool is aimed at Java vulnerabilities.

    Worcel said that most vulnerabilities can be traced back to eight types of mistakes that developers routinely make. The company created a pattern for those common mistakes, along with patterns to fix them, called Mobb rules. That ability enables Mobb to accurately produce a code fix that both remediates the vulnerability and adheres to the correctness of the language to eliminate code defects. Mobb then makes available a patch to address those issues in a way that can be readily downloaded and applied by developers. Mobb does not automatically apply those fixes because most developers prefer to review them first, noted Worcel.

    The Mobb approach eliminates the need for IT teams to sort through SAST scans themselves, which can result in the discovery of thousands of vulnerabilities that might theoretically need to be fixed. Each vulnerability, at minimum, is going to require 30 minutes to fix, so the Mobb platform provides a better return on investment and reduces patch backlogs, added Worcel.

    For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing which types of vulnerabilities should have a higher remediation priority.

    Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities being discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool addresses that later issue by automatically creating the necessary patch, said Worcel.

    Many organizations just allocate junior developers to the task of remediating vulnerabilities, which Worcel noted frees up more experienced developers to focus on writing additional business logic.

    There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that have already been developed.

    One way or another, the process by which patches are prioritized, developed and then applied has long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities wherever they may be found.

  • A Seven Point Checklist for Getting SAST Right

    A Seven Point Checklist for Getting SAST Right

    With so many physical products—from automobiles to airplanes and medical devices to industrial control systems—now being driven by software, product security has become a top-level concern for manufacturers. Software flaws can not only affect security by introducing vulnerabilities that can be exploited by attackers but also impact safety by compromising a product’s functional operation.

    In addition, product security has significant financial implications. For example, fixing a vulnerability in development costs 10 times less than in testing and 100 times less than fixing it in production. This explains why static application security testing (SAST) has become a cornerstone of product security and the engine for implementing code analysis at the earliest stages of development, commonly known as shift left security.

    Unlike other forms of application security testing (AST), SAST scans 100% of the code, including configuration files, not just the code that is executed at runtime. SAST can also provide additional benefits, such as quality and architectural testing. Software quality and security are inextricably linked since poorly written software typically is insecure software.

    With the stakes so high, getting SAST right is the tipping point for any product security program. To evaluate SAST tools, consider the following checklist to make sure they align with your business requirements:

    1. Deep Language Support: C/C++, Java, C#, etc.

    Languages are often selected based on the programmatic requirements of the software producer, the needs of the consumer and the hardware associated with the product. For example, developing software for safety-critical applications like aerospace requires different capabilities than languages used to build web applications.

    2. Compiler and Embedded OS Platform Compatibility

    Compilers used for embedded software development implement unique flags for configuration, such as performance optimizations, code size, error checking and the diagnostic information emitted. Since embedded OS platforms typically include compiler and debugging tools plus the various OS files and configuration options, make sure the SAST tool can integrate with the development environment used.

    3. Actionable Alerts

    For the DevOps team to embrace security, embedding security in the software factory life cycle cannot slow down development velocity or hinder developers’ ability to meet software release timelines. False positives redirect developer attention away from writing software to investigating potential defects. Too many false positives result in developers losing faith in true positives and paying less attention to security alerts of real substance.

    4. Built-In DevOps Integration

    The software development life cycle employs an extensive toolset that provides automation to help developers get products to the production stage faster—not unlike a manufacturing plant or factory. Make sure the SAST tool supports and integrates with distinct tool categories including collaboration and management, source control and repositories, IDEs, compilers, orchestration and automation and business intelligence.

    5. Flexible Deployment

    Depending on the organization and industry, SAST may need to support a variety of deployment options, including on-premises, cloud, hybrid, etc. For example, air-gapped deployments are often required in security-sensitive environments where the data protection uncertainty associated with multitenant public clouds is unacceptable. Meanwhile, cloud-based SAST can provide benefits like scalability and elasticity and reduce infrastructure capital investments.

    6. Developer-friendly UI

    Shift left security is accomplished by integrating security warnings into the integrated development environment (IDE) used by engineers. A SAST tool that works within existing IDEs can reduce the number of errors presented to testers, which subsequently reduces the volume of kickbacks to engineering and leads to faster time-to-market.

    7. Standards

    Many organizations use—and some must comply with—standards for software coding best practices such as SEI CERT, MISRA, etc., which provide a framework for improving the safety, reliability and security of software systems. In addition, a company may need to satisfy functional safety standards such ISE 61508, as well as derivative industry specific standards including IEC 62304 (Medical), ISO 26262 (Automotive),  DO-178C (Avionics) and IEC 62434 (Security). A SAST tool should provide integration with key standards that govern an organization’s products and, where appropriate, be certified for them.

    Using these guidelines for evaluating SAST tools will help ensure that the product you select meets your organization’s business, technology, safety and security requirements.

  • Addressing Software Supply Chain Security

    Addressing Software Supply Chain Security

    It’s essential for organizations to learn more about the software supply chains they rely on and the steps needed to secure them. In just the past few years, we have seen a major uptick in malicious actors exploiting vulnerabilities in software supply chains to facilitate attacks on organizations. However, it’s important to remember that these attacks are not a new phenomenon. In fact, they’ve been around for decades. Therefore, the need to secure the software we rely on is not new, though the industry turning its attention to this problem is.

    Software supply chain attacks are also far from simple. Given the fact that software supply chains are highly complex and made up of a number of constantly changing components, the avenues that malicious actors can take to pull off an attack are plentiful. For example, software artifacts are partially made up of components downloaded from open source software repositories. These platforms have become a favored attack avenue, given how frequently they are used by developers and the trust extended to them by development organizations. According to GitHub, anywhere from 85-97% of enterprise codebases come from open source repositories. Two of these repositories, npm and PyPI, have seen a nearly 300% spike in the number of attacks on their platforms in the past four years, impacting thousands of software supply chains globally.

    One example of the kinds of software supply chain attacks that are now common is IconBurst, a major attack from last year where more than two dozen typosquatted packages were discovered on npm. As with other recent attacks, the IconBurst attackers used typosquatting – uploading malicious packages to repositories with names that closely resemble popular and legitimate packages on the same platform. Developers, in a rush to complete their work, are often tricked into downloading these typosquatted packages. In the case of the IconBurst campaign, for example, one of the malicious packages discovered was downloaded over 17,000 times!

    Given the significant increase in the number of software supply chain attacks, organizations must make more of an effort to understand how these attacks work and then take steps to secure their software supply chains from compromise.

    Say Goodbye to “Shift Left”

    To begin with, development organizations need to reevaluate the mantra to “shift left.”

    For years, industry leaders promoted the notion of “shifting left” as a call to marry application security with application development: Embedding secure development tools and practices into the continuous integration/continuous delivery (CI/CD) process. But times are changing and the industry is beginning to understand that while shifting left is necessary, it is not sufficient to secure software supply chains.

    “Don’t shift left; shift everywhere!” said Tanya Janca, founder and CEO of WeHackPurple. Janca was speaking as a member of a recent Techstrong panel, “Software Supply Chain: It’s All About The Code” at the Predict 2023 virtual event. Janca pointed out the industry’s past fixation on “shift left” and the gaps in security that this caused since threats to the software supply chain not only happen during development but also throughout the entire software release process.

    In fact, the notion of shifting left may do development organizations and developers a disservice: Leaving the work of securing applications entirely to them. “It’s unfair to expect developers to write perfect code,” said Jeff Williams, co-founder and CTO of Contrast Security, another member of the panel.

    Software engineers are already under pressure to develop software quickly to meet development and project milestones. That makes it difficult for them to implement perfect security measures, like vetting every single line of third-party code they use while also watching out for social engineering attacks.

    A New Approach to Secure the Software Supply Chain

    For organizations looking to secure the software supply chains they rely on, they must choose the right tools. But much of the secure development and application security testing (AST) technology out there won’t cut it. For instance, tools such as dynamic or static application security testing (DAST/SAST) are critical components of the secure development life cycle (SDLC). However, they don’t provide holistic coverage of all of the supply chain threats out there, including software tampering and the risk posed by compromised open source and third-party libraries. On the other hand, tools such as software composition analysis (SCA) can help vet open source components but often fail to detect malicious modules or provide total security coverage of software supply chains. Knowing that your application depends on a malicious open source package after the fact is of little consolation when you release code at the speed of DevOps.

    This is why modern tools that go beyond these capabilities should be considered. “It’s about giving developers the tools they need to be successful,” said GitLab’s CPO David DeSanto at the event. Experts in the space agree that change is needed but that developers and development teams aren’t set up for success as it stands.

    According to Mat Matthews, an experienced practitioner in the DevOps space: “While developers are responsible for ensuring clean code, it takes a cross-functional team with a specific focus on security to reduce the attack surface against supply chain attacks.”

    To accomplish that, organizations need to look to their security operations centers (SOCs) to take on a greater role in helping to secure software supply chains. Close collaboration between development and SOC teams is the surest way to provide end-to-end security for an organization’s software supply chains. And, supplied with the right tooling, SOCs and development teams working together will be better positioned to scan software packages; achieve greater visibility into development processes; detect deviations from a set baseline; and pursue possible supply chain compromises before they can cause real harm to software publishers and their customers.

    As threats and attacks on software supply chains evolve, so must protections. A modern software supply chain security program should aim to protect the entire software development process, from the developer IDEs and their plugins to the open source components, CI/CD workflows and the release pipelines, while also being equipped to spot and pursue compromises at any point in the development life cycle. Only then will development teams be able to prevent harmful attacks like SUNBURST, IconBurst and countless others that have happened since.

  • Update to Open Source ZAP Tool Improves DAST Performance

    Update to Open Source ZAP Tool Improves DAST Performance

    An update to the OWASP Zed Attack Proxy (ZAP) open source dynamic application security testing (DAST) tool made available today improves performance by employing a multi-threaded passive scanner engine.

    Version 2.12.0 of ZAP also adds support for HTTP/2 and should make it simpler to update the vulnerability scanning tool by making the spider that discovers new resources an add-on that is now capable of discovering more URLs.

    ZAP is an open source penetration testing tool maintained by the Open Web Application Security Project (OWASP) designed specifically for testing web applications.

    Simon Bennetts, founder and chief maintainer of ZAP, said the latest update will make it simpler for developers to discover vulnerabilities in their code faster. One of the reasons developers often don’t frequently scan their code for vulnerabilities is because the scans are perceived to be slow, he said. Of course, the longer a developer waits before scanning their code the longer it will take to complete the scan.

    DAST tools are a critical element of any DevSecOps workflow because they enable developers to view weaknesses in application security as an attacker would—by analyzing a web application through its front end. That approach doesn’t eliminate the need for static application security testing (SAST) tools to discover vulnerabilities in source code; rather, a DAST tool helps developers better understand how cyberattacks target specific types of vulnerabilities in their applications, noted Bennetts. As an open source tool, ZAP is intended to remove the barriers to adoption of DAST tools by making it simpler for developers to download and install themselves, he added.

    Interest in DAST tools is, of course, rising in the wake of a series of high-profile attacks against software supply chains. The debate that has ensued is how far to shift application security responsibility left toward application developers. More organizations are starting to require developers to embed security tools within their application development tools. Others are also embedding various types of security tools within their DevOps workflows to ensure scans are run should developers fail to do so.

    No developer sets out to build an insecure application, of course. The primary issue is that many of the DAST tools being provided are not designed to be employed by developers, said Bennetts. Instead, they are designed for cybersecurity teams that then share results with developers after an application has been constructed, he added. That approach creates a dysfunctional relationship between application development and cybersecurity teams because developers are being asked to remediate vulnerabilities long after code was initially written, said Bennetts. In most cases, those developers have moved on to other projects so any context for how code was constructed is often lost, he noted.

    Implementing DevSecOps best practices is, naturally, as much about culture as it is the tools being provided. However, the one thing that is clear is that tools adopted willingly by developers are going to be much more widely used than tools chosen by others on their behalf. In many cases, the shortest path to improving the overall state of application security is going to be an open source tool that developers can readily access themselves.

  • Three Ways to Speed up SAST

    Three Ways to Speed up SAST

    In modern, continuous software development life cycle (SDLC) processes, when code is written and before it’s committed to the repository, it’s run through testing, which may include unit testing, regression testing or static application security testing (SAST). The benefit of SAST for DevSecOps is the real-time feedback it provides developers as they create and make changes to the source code before they submit it. The amount of time that’s acceptable in this kind of workflow is 15 minutes to 30 minutes maximum, with some allowance for how big the change is. Fast feedback means quicker turnaround and more progress on features. The business value lies in those features. Testing makes sure they work.

    Depth Versus Breadth

    Checkers used by SAST are not all created equal, at least in terms of the computation power needed. The time for analysis is directly related to the complexity of the checkers used to detect certain types of vulnerabilities. Typically, coding standard enforcement rules are easier to compute versus complex tainted data analysis used to detect command or SQL injections, for example. Therefore, there is a trade-off to be made in the types of bugs and vulnerabilities being detected. When developers are coding, it makes sense to optimize the compute time for SAST to reduce any delays. During software builds, more time and compute power is available so depth and breadth can be increased to catch complex vulnerabilities.

    Compute Power

    SAST analysis time scales well with compute power. The availability of more computing resources such as CPU and memory, can impact the time of analysis. Bigger is better in this case and investing in additional hardware for SAST can pay off in terms of productivity.

    Codebase Size

    SAST analysis time is also dependent on the amount of source code analyzed. Depending on the application, the code base is a determining factor in terms of what depth and breadth of analysis is optimal.

    There is some correlation between small code base size and strict requirements for SAST such as in safety-critical software. It’s expensive to build and test safety-critical code, but code size is typically smaller than in other types of applications. However, these products need to conform to industrial coding standards and thus require rigorous levels of testing and analysis to detect a wide variety of defects.

    Larger and extremely large code bases require a trade-off in terms of depth and breadth of analysis. Prioritizing the types of defects and vulnerabilities to concentrate on is critical.

    Speeding up SAST means reducing the amount of work. The most intensive operation is a full analysis of the entire source code base. Just as full compilation from scratch takes a long time, the same is true of SAST analysis.

    To accelerate SAST processing times, follow the same three techniques used to avoid compilation in large C/C++ projects: incremental analysis, component analysis and developer analysis.

    1. Incremental Analysis

    Incremental builds are a major factor in reducing developer build times for C and C++ projects. Small changes don’t require the entire code base to be recompiled. It’s impractical and unnecessary. When a developer modifies something, only what’s needed to be recompiled gets recompiled automatically, and the build infrastructure handles it.

    SAST works in a similar manner. As source code is being compiled, SAST parses the same source code and creates a program model. The second phase is analyzing that program model against the configured checkers and generating warnings. The warnings typically go into a database for later analysis.

    During the build of the software, SAST is run in parallel. Although similar to a compiler in operation, SAST must do more work than the compiler and takes longer to finish and provide results. The amount of code needed to recompile for each change directly impacts analysis time.

    Meanwhile, SAST of an incremental build requires a lot more work than just analyzing the changes. SAST uses abstract execution of code flow through multiple different compilation units. So even though a single file is modified, the calls it makes to other files need to be analyzed as well. The incremental analysis doesn’t increase the build and parse workload, but the analysis scope will be a lot bigger than expected. So, whenever you do an incremental build, SAST will need to reanalyze the dependencies, changes and related bits and pieces around those changed units.

    Nevertheless, it remains a good option for reducing SAST analysis times.

    2. Component Analysis

    If the software being developed has a loosely coupled, component-based architecture with well-defined interfaces, it’s possible to isolate both the testing and the SAST analysis to the component where changes were made. Just as this type of architecture simplifies many aspects of development, it pays off with SAST as well. It’s possible to analyze the component in isolation and get good results.

    3. Developer Analysis

    To further reduce SAST workload, start the first build without SAST, which removes the burden of the extra computation needed. Since subsequent builds are a lot smaller and build speed is much faster.

    However, there is an increase in false negatives due to the smaller scope of analysis since only files that changed are analyzed. This smaller scope means that all possible dependencies are outside the program model and are not considered in the analysis. However, this rapid analysis works well with coding standard enforcement, for example.

    Developer SAST

    Where to Start?

    Begin with a full build and analysis. This sets a baseline for detected bugs and vulnerabilities and establishes a performance target for reducing build time. This step will determine the exact number of lines of code, how long the analysis takes and its impact on build server load. These metrics should drive the analysis optimization effort.

    Given the options, the first step should be a component-based analysis. If this works well, it’s still possible to further reduce analysis with incremental and developer analysis within components. This approach can be integrated into typical developer workflows.

    When creating a developer branch for implementing changes, quick developer local analysis will catch local errors. These tend to be the largest set since they represent the largest part of the code changes. When enforcing coding standards, this is the point where violations are identified. A full analysis is recommended on a merge request to detect remaining defects related to cross-component-boundary behavior.

    Speed up SAST

    To speed up SAST consider using these techniques at the appropriate development stage to reduce time to complete, while still producing excellent results. Keep in mind that:
    ● Complete analysis yields the best and most precise results,
    ● Incremental analysis only analyzes recompiled code that has been modified,
    ● Component analysis works well in software that follows a well-defined component architecture and
    ● Developer (local) analysis provides a good compromise of precision and analysis time.

  • Cycode Expands Scope of AppDev Security Platform

    Cycode Expands Scope of AppDev Security Platform

    At the Black Hat USA 2022 conference, Cycode this week announced it has added static application security testing (SAST) and container scanning capabilities to its software composition analysis (SCA) platform that is based on a graph database.

    Amnon Even-Zohar, director of product management for Cycode, said the addition of these tools brings to eight the total number of modules that are now integrated with its Knowledge Graph database. Those modules address application security requirements spanning everything from infrastructure-as-code misconfigurations and DevOps pipelines to binary and source code analytics in a way that reduces both the number of false positives being surfaced, he added.

    That approach makes it possible to provide more context to software remediation efforts by pulling data from across the entire software development life cycle rather than focusing solely on vulnerabilities found in source code, he noted. Cycode, for example, can pinpoint where vulnerable dependencies are found in test and production environments, said Even-Zohar.

    A Cycode Pipeline Composition Analysis tool also provides insights into which components enable a vulnerability or security issue, how pipeline components relate to each other and if they are present in runtime environments, he added.

    While there’s a lot of interest in implementing DevSecOps best practices in the wake of a series of high-profile AppSec breaches, many organizations still lack the tools required to secure an application development environment on an end-to-end basis. The Cycode platform leverages the data that already exists in DevOps workflows to enable organizations to better prioritize their remediation efforts and lower the total cost of doing so, said Even-Zohar.

    The goal is to not only enable organizations to shift cybersecurity further left toward developers but also further right by more closely integrating cybersecurity and DevOps teams, he noted.

    The DevSecOps challenge that most organizations are trying to navigate is that, historically, a list of vulnerabilities discovered by cybersecurity researchers is shared with DevOps teams without much context. Developers don’t know which vulnerabilities are most critical or, for that matter, whether the vulnerability identified is actually present within their application environment. SCA tools, in theory, could make it easier to identify, for example, where a Log4j or a shell vulnerability might be found. Graph-based tools take that capability to the next level by making it easier to visualize where any instance of a vulnerability might be found. In the absence of such tools, IT organizations would spend weeks looking for each instance of a vulnerability.

    It may be a while before DevSecOps workflows become commonplace but at the very least there is now more awareness of software supply chain security issues. The Biden administration has also issued an executive order that requires federal agencies to review the security of software supply chains. Many enterprise IT organizations are now following suit. One way or another, application security is going to improve. The only thing that remains to be determined is what impact those improvements will have on the rate at which software can be built and deployed.

  • Turning Off DevSecOps Noise for Functional Fidelity

    Turning Off DevSecOps Noise for Functional Fidelity

    Analyzing the DevOps and DevSecOps software marketplace demonstrates the high demand for tools and platforms that reduce false positives. As businesses and organizations adopt a rigorous, disciplined software development life cycle and ascribe to strict compliance frameworks, they quickly realize that automated tools can generate a substantial amount of noise, in the form of false positives, that pollute their efforts to maintain a lean and focused operation.

    True Positive Vs. False Positive Vulnerabilities

    Static application security testing (SAST) is fundamentally about using pattern recognition to identify vulnerabilities in code. The more aggressive the scan rules, the more likely a snippet of code will be flagged as a vulnerability; in other words, a “true positive” finding. Automated scanning is fundamental to effective DevSecOps. But if the scanning is too aggressive, it may generate findings that aren’t actual problems; in other words, false positive findings 

    You want your scan to return true positive findings—actual vulnerabilities that can be fixed and remediated. A false positive is a finding that isn’t actually a vulnerability. The ideal tool catches all the true positive vulnerabilities and returns a minimal number of false positives.

    Many platforms give their users granular control over which rules run and are applied to their code. This first layer of control is similar to allowing your team to tune their scans to focus only on certain frequencies while ignoring others. Often, this is used to increase the speed with which a platform might complete a scan. It can also be used to tune out “noisy” rules. It’s perfectly legitimate to use controls like these, but it’s important to recognize that those completed scans aren’t comprehensive.

    Speeding Up Can Slow You Down

    Positive findings, whether they are true or false, take more time and resources to evaluate and remediate. Investing resources to remediate true positives is worthwhile. It would be ideal if they had been caught earlier in the process, but catching a vulnerability before it hits production is the entire reason you are doing DevSecOps in the first place! False positives may not require actual remediation, but reviewing them and then manually confirming their false nature is directly counterproductive to the reasons an organization adopted automated SAST in the first place.

    SAST Plus DAST Keeps You Ahead

    The gold standard for effective security testing is to pair SAST with dynamic application security testing (DAST), sometimes also called interactive application security testing (IAST). This process will correlate the positive findings from the SAST scans and test them using simulated data in an emulated runtime environment. 

    DAST/IAST actually tests each bit of code that looks problematic because of a particular pattern and then tests whether the code is actually vulnerable. DAST provides an automated, testable, repeatable and provable method to test those positive findings for trueness and falseness. If you are only doing SAST scanning, then the noise-to-signal ratio from your platform is governed strictly by the intelligence embedded into their pattern-matching code. Depending on the quality of the tool being used, your actual mileage may vary.

    DevSecOps Is the Right Path

    Businesses and organizations clearly understand the problem of potential vulnerabilities. Guarding against a security breach is critically important to protecting proprietary information and the privacy of their customers. DevSecOps is clearly the right path to take to reach that goal. However, it is critically important that the vehicle(s) these teams use to get there (in this case, SAST and DAST/IAST) have built-in functionality to focus their efforts on real problems and not waste it on phantom issues.

  • Quick! Define DevSecOps: Let’s Call it Development Security

    Quick! Define DevSecOps: Let’s Call it Development Security

    For a good long while, DevSecOps referred specifically to vendors like Veracode that did static application security scanning, dynamic application security scanning, software composition analysis and some form of runtime monitoring (usually interactive scanning). Then we realized that DevSecOps was potentially a lot more than that and, like DevOps, we drove the word to encompass all things that shift security left.

    That’s where we are now. But that leaves the DevSecOps market confusing to a lot of people. I propose we rename the tools that specifically focus on code quality to Development Security—even though that name is not perfect and all-encompassing. It’s a better fit than terms in other spaces, like Password Management, which includes two-factor authentication (2FA), multifactor authentication (MFA) and, increasingly, passwordless and secrets management, none of which actually use passwords for the focus of their functionality.

    This way, we can all understand that DevSecOps is the mindset and methodology and Development Security is one piece of implementing DevSecOps.

    There are probably people smarter than I am who have come to this (or alternate) conclusions, and I’m happy to run with their solutions, too—this is just an attempt to make it less confusing for those who don’t live and breathe the security and DevOps markets. If a new person says, “I think we need DevSecOps,” they are in for a journey to actually figure out what they meant and if what they need is actually DevSecOps. We should strive to clarify that so, at the beginning of their research, it is clear that DevSecOps is like DevOps—an overarching term for policies, procedures, mindset and products while the tools that can help with DevSecOps, like those that make up the overarching DevOps toolchain, belong to a market segment named X. In my case, I proposed Development Security because it’s a close fit. What we actually call it is irrelevant, as long as new people understand it is a subset of DevSecOps.

    While you continue to keep the systems spinning and the organization online, when you research these products, use phrases like, “I’m looking for Development Security tools that fit with a DevOps environment.” Markets are largely named by vendors and pundits but, in the end, all these people want to talk in terms their customer base recognizes. So, if enough of you ask for Development Security, that’s what they’ll all start calling it. Effective immediately, that’s what I’m calling it. It is a distinctive set of functionality that all orgs who do internal development need, so let’s give it a distinctive name. And yeah, drop me a line if you have a better name. I’m tied to making it easier, not to a specific term.

  • WhiteSource Becomes Mend, Launches Automated Remediation Platform

    WhiteSource Becomes Mend, Launches Automated Remediation Platform

    WhiteSource rechristened itself Mend today and launched a remediation platform that automatically resolves security issues for application developers.

    Rami Sass, co-founder and CEO of Mend, said now the company is going beyond just identifying vulnerabilities in open source software using software composition analysis (SCA) tools and is also fixing them. The overall goal is to make it simpler for developers to address security issues without taking time away from writing code or slowing down the rate at which applications are developed, he added.

    To further that effort, Mend also announced today it is making available a plug-in for JFrog Artifactory that enables Mend Supply Chain Defender, formerly WhiteSource Diffend, to enable detection of malicious open source code. Last year the company acquired Diffend followed by the acquisition of two startup providers of static analysis security testing (SAST) tools.

    Collectively, those applications enabled the company to build the Mend Application Security Platform, a software-as-a-service (SaaS) offering that combines SCA and SAST tools to create an automated remediation framework that can be applied to both open source and proprietary code residing in a repository.

    Mend claimed it added more than 350 customers in the last year to bring its total to more than 1,000 organizations. Most recently, the company raised an additional $75 million in financing to continue investing in a platform specifically designed to address application security issues. In the wake of a series of high-profile security breaches involving software supply chains, Sass noted there is now a much greater appreciation for securing applications and that demand for application security solutions is growing. That demand, in turn, is fueling a wave of consolidation that is, in part, enabled by the convergence of application security tools made available via a SaaS platform, he added.

    Historically, much of the focus on application security focused on discovering vulnerabilities that developers are asked to patch. The issue is that developers are being asked to patch the same modules repeatedly. The Mend Application Security Platform keeps track of what modules have been successfully updated to give developers higher confidence in the updates being applied, said Sass.

    Those recommendations are not being surfaced using machine learning algorithms but rather by the data analytics capabilities that have been added to the company’s portfolio of tools over time, he noted.

    While there may never be such a thing as perfect security it’s apparent that most application security issues can be traced back to relatively common mistakes that developers routinely make. The more those issues are surfaced within a developer workflow, the less dependent organizations will need to be on embedding guardrails within DevSecOps workflows to prevent vulnerabilities from finding their way into production environment. The Mend Application Security Platform doesn’t eliminate the need for those guardrails as much as it reduces the sheer volume of security issues that might otherwise need to be addressed.

    It may be a while before these more advanced developer security tools achieve that result, but it’s clear from how quickly advances are being made that such tools should have a material impact on the overall state of application security.