Tag: devsecops

  • Progress Acquires Chef to Expand DevOps Portfolio

    Progress Acquires Chef to Expand DevOps Portfolio

    Progress today announced it has acquired Chef for $220 million in cash as part of an effort to advance adoption of best DevOps and DevSecOps practices in the midmarket.

    Once the deal is completed next month, Chef will operate as an independent business unit led by Sundar Subramanian, who currently is a senior vice president and general manager at Progress.

    Progress CEO Yogesh Gupta said IT automation technologies developed by Chef will be incorporated into monitoring and debugging platforms and tools that Progress currently provides. By moving into areas such as compliance and security, Chef has already embarked on an effort to make its offerings more accessible to IT personnel, who often lack programming skills, especially in midmarket IT organizations that make up the bulk of the Progress customer base.

    As a private company owned by venture capitalists who monetized open source software mainly via commercial support agreements and enterprise editions of its software, Chef has been able to generate roughly $70 million in revenue. As an arm of Progress, Chef joins a public company with more than $500 million in revenue that has a market capital in excess of $2 billion.

    Chef should be in a better financial position to compete against rivals such as Puppet and Red Hat. Following its acquisition by IBM, Red Hat has been plowing consider resources into a declarative Ansible automation framework that tends to appeal to traditional IT teams. In comparison, Chef has been a pioneer in automating IT using programming tools that especially appeal to DevOps teams managing infrastructure as code.

    In general, most midmarket IT organizations don’t have a lot of DevOps expertise. As an independent arm of Progress, Chef will continue to focus on IT operations, compliance and security, while Progress focuses more of its efforts on the application development and deployment requirements of midmarket organizations, said Gupta. As midmarket IT environments become more complex, the number of touchpoints between Progress and Chef involving cookbooks and recipes created by Chef will increase over time, he added.

    The acquisition of Chef is the latest in a wave of consolidation across the DevOps category. While adoption of DevOps tools and platform continues to grow, traditional enterprise IT organizations are now moving to acquire many of the larger vendors in the DevOps category. That trend is only likely to accelerate during an economic downturn brought on by the COVID-19 pandemic. At the same time, the number of startup companies being launched continues to expand the overall size of the DevOps/DevSecOps ecosystem.

    It’s too early to say at what rate best DevOps practices will gain further traction among traditional midmarket IT organizations. However, at a time when many of those organizations are being asked to do a lot more with even less, it’s only a matter of time before existing rigid IT processes begin to incorporate more agile approaches to managing IT as a matter of survival.

  • Fastly Sets DevSecOps Strategy After Signal Sciences Buy

    Fastly Sets DevSecOps Strategy After Signal Sciences Buy

    In the wake of acquiring Signal Sciences for $770 million, Fastly is gearing up to expand the range of security services it offers as part of an effort to advance adoption of best DevSecOps practices.

    Artur Bergman, chief architect for Fastly, said a forthcoming wave of edge computing applications will require web applications firewalls (WAF) that can be deployed and managed remotely to protect them. As a provider of a content delivery network (CDN), Fastly will leverage the WAF platform developed by Signal Sciences to secure edge computing platforms within a forthcoming Secure@Edge service that promises to unified web application and application programming interface (API) security.

    Fastly has been gaining ground as a provider of CDN services that are programmatically designed from the ground up to shift control over networking and security services further left toward DevOps teams, said Bergman. In many cases, the only way to secure workloads running on an edge computing platform is for DevOps teams to be able to programmatically deploy a WAF to protect the workloads on that platform, he noted.

    Edge computing platforms are especially vulnerable to distributed denial of service (DDoS) attacks that are increasing in both size and sophistication as cybercriminals become more adept at targeting specific servers and platform, added Bergman. No one can prevent a DDoS attack from being launched, but a CDN can play a critical role in mitigating its impact.

    The acquisition of Signal Sciences comes on the heels of Fastly’s move to expand its the ability to collect metrics from edge computing platforms that will be employed to extend the reach of monitoring tools employed by DevOps teams to edge computing platforms.

    Zane Lackey, chief security officer for Signal Sciences, said the two companies share a similar history and commitment to best DevOps practices. The WAF from Signal Sciences is based on a runtime application self-protection (RASP) architecture that only runs when an application fires up, which Lackey said makes it a natural extension of any DevOps toolchain.

    The Signal Sciences WAF is unique in that it can support multiple classes of monolithic and microservices-based applications and that 95% of organizations that employ it do so in full blocking mode because the number of false positives the WAF generates is limited, added Lackey.

    Naturally, Fastly is not the only provider of a CDN services looking to woo DevOps teams. Organizations have been deploying web-based applications on CDNs for years. However, CDNs that simplify the deployment of applications within the context of a DevOps workflow are gaining traction.

    It’s too early to say how this battle will play out. In addition to providers who have built their own global networks, cloud services providers also now offer CDNs that promise to optimize cloud application performance while enhancing security and simplifying deployment. Regardless of the path forward, it’s clear that as more latency-sensitive applications are deployed across distributed computing environments, the more inclined DevOps teams will be to rely on external network services that can adapt quickly to changing application requirements.

  • DeepFactor Unifies Performance and Security Monitoring for Developers

    DeepFactor Unifies Performance and Security Monitoring for Developers

    DeepFactor today launched what it describes as the first continuous monitoring platform designed specifically for pre-production environments.

    Company CEO Kiran Kamity said the DeepFactor Pre-Production Monitoring platform combines security, performance and behavior monitoring in one offering. Based on a “Deep Passive Monitoring” capability that requires developers to add a file to a container image to instrument an application, the platform feeds the telemetry data collected via that file to an Application Runtime Intelligence engine. That engine surfaces potential security and performance issues as well as risky and unexpected behavior changes between versions of applications, he said.

    Scans of application environments are launched via a DeepFactor portal. Each scan is then compared to a set of configurable rules that are developed and maintained by the DeepFactor research team to identify indicators of application misbehavior. The engine also learns the application environment, which over time enables DeepFactor to generate alerts based on threshold triggers, known bad behaviors, anomaly detection and other attributes.

    The DeepFactor Pre-Production Monitoring platform also comes with pre-packaged integrations for widely employed DevOps tools including Jira, Jenkins, Slack and GitHub.

    In addition to the commercial platform, DevOps teams can also make use of a DeepFactor Standard Edition, which is free for non-commercial open source projects with no user limitations.

    In an ideal world, developers would address issues, including security, long before an application is deployed to a production environment. The issue is that developers are asked to navigate too many tools to achieve that goal. The DeepFactor Pre-Production Monitoring platform will make it easier for developers to surface insights in a frictionless way, said Kamity.

    Most organizations that embrace best DevOps practices embrace observability as a core tenet. The challenge they face is making it easy for developers to instrument applications as they are built and then making sense of all the telemetry data collected. That’s especially critical as developers attempt to strike a balance between remediating security issues and optimizing performance to better ensure the overall user experience. Existing developer tools are optimized for performance; asking developers to switch tools to address potential cybersecurity issues is a task that can be delayed to the point where it is essentially forgotten or simply ignored.

    It’s not clear to what degree DevOps teams might have the budget dollars required to deploy their own monitoring tools versus relying on the existing monitoring tools provided deployed by an IT operations team. However, it does usually take a significant amount of time to deploy and update the agent software that legacy IT monitoring platforms require. DeepFactor is making the case for capturing telemetry data using a comparatively lightweight container that can be added to either a monolithic or microservices-based application.

    Of course, if an application is already instrumented in a pre-production environment it might make sense to use the same monitoring platform to observe applications in a production environment. However, convincing IT operations teams to swap out their existing monitoring tools for something that makes the lives of developers easier might be a tall order.

  • 7 Things to Make DevSecOps a Reality

    7 Things to Make DevSecOps a Reality

    While talking about DevSecOps has become a hot trend, it is clear that many organizations claiming to follow such methodologies are actually mired in traditional waterfall development. Let’s figure out if you’re really ready to implement DevSecOps.

    In a world that relies heavily on distributed computing and third-party services, security is paramount for those who want to remain competitive. From open source applications to operating systems developed, deploying, delivering and correcting application vulnerabilities must occur rapidly before breaches or compromises occur.

    Here’s the good news: If your company practices authentic agile development and uses highly modular design patterns such as service-oriented architecture, you are well-positioned to achieve DevSecOps success. Why? Because you are already using key strategies that provide solid foundations for secure computing solutions, so you can immediately start experiencing the benefits that come from doing DevSecOps right.

    Follow the Exact Recipe: Don’t Cherry-Pick Ingredients

    DevSecOps emerged from people realizing that DevOps did not adequately highlight security concerns and security should be shifted farther left in the software development life cycle. You should think of DevSecOps as sweetening the existing “recipe” of DevOps by baking security in from the beginning without slowing down the development and release cycles. It may sound obvious, but increasing velocity while reducing risks will guarantee the release of better products because they are built with potential risks in mind (for instance, more and better error handling). This approach results in happier customers and repeat business, which will positively impact your bottom line.

    DevSecOps Requires a Shift in Culture and Mindset

    Let’s face it, the days of successfully deploying applications designed to meet business demands without embedding security controls early in the development life cycle are gone. Effective DevSecOps spans culture, practices and tools that break down silos, orchestrate integrated processes with automated tasks and simplifies security by bringing it out into the open. Instead of “security through obscurity,” boundaries and channels are clearly defined and narrowly focused.

    The benefits of DevSecOps are many and include:

    • Automating security review and application testing.
    • Increasing the speed of delivery enhances product quality.
    • Enhancing compliance with continuous monitoring and auditing.
    • Fostering transparent and open cultures.
    • Reducing costs, development church and application attacks.
    • Delivering increased security and confidence.

    A methodology that uses communication and collaboration to allow for dynamic development and deployment is crucial for responding to change and needs rapidly. When done right, this new mindset will make everyone in your organization accountable for security with a simultaneous mind and talent shift.

    Putting DevSecOps Into Practice: A Checklist

    An efficient DevSecOps program will require continuous management and developer education and process improvement through open collaboration, proactive monitoring and informed feedback. Here’s a short checklist to ensure you’re on the right path.

    1. Build an Environment Conducive to DevSecOps: Engage leaders with a new mentality that makes it incumbent on leadership to understand engineering practices, so they know when things need shorting up. Deeply integrate management, so they support the necessary investments in tools and training while encouraging teams throughout the entire development life cycle.
    2. Ensure Open Communication and Active Training: Promote collaboration and ongoing learning that leads to continuous improvement across the organization. Do this well by providing developers with the training and tools they need. Enable failing fast, early and often so you learn from it and create something useful.
    3. Adopt a Security-Conscious Culture: The driving force behind DevSecOps requires security to be defined at the beginning of a project for repeatable, consistent use. This practice will help you respond to security needs and changes quickly while increasing team collaboration.
    4. Implement Infrastructure as Code (IaC): Without relying on manual processes, IaC helps manage and provision infrastructure automatically. This approach allows code to automatically be rolled out in a repeatable and consistent manner through a version-control system instead of relying on installation gurus and “component owners.”
    5. Use Genuine Agile: Instead of cherry-picking from the agile approach and using your own form of agile-flavored waterfall—focus on practicing “Pure Agile.” This method includes detailed and frequent stakeholder involvement, “fail fast” practices and processes, a “meet the requirements” values and principles mindset and technical excellence.
    6. Adhere to Modular Design Patterns Closely: While object-oriented design (OOD) and service-oriented architecture (SOA) mean different things to different people, the commonly understood key is decomposing large business problems into small business problems that can be addressed by discrete services through boundaryless information-flow sharing.  When done correctly, OOD and SOA will help your applications scale quickly while decreasing costs.
    7. Favor Resource Management over Pride of Ownership:  There is a now-famous analogy about thinking of software components more like cattle than like pets.  While grim, the point is a salient one: When something fails, you should be able to quickly replace it with a new or improved component instead of trying to nurse the ailing component back to health. This mindset better promotes modularity and discreteness of purpose, which, in turn, leads to faster fix and restoration times.

    As virtual environments and cloud usage grow, the need for DevSecOps to be done “the right way” is growing right along with it. But the sense of urgency to implement DevSecOps practices “the right way” hasn’t quite caught up yet. The challenge is to embrace all aspects of DevSecOps day in and day out, instead of just going through the motions of the select practices you adopted.

    The call to action is clear: Now is the time for organizations to move the speed of delivery and secure code out of the textbooks and manifestos into the mainstream.

  • DevSecOps and Passwords: Lessening the Burden

    DevSecOps and Passwords: Lessening the Burden

    The point of DevOps is to make IT more responsive (and hopefully more stable, but we have evidence that is not always the case). The point of DevSecOps (so far) is to make security more responsive and to build security right into the stack. These are both worthy goals. As we all have pointed out repeatedly, an already overworked security team needs DevSecOps to keep up with the increased rate of change that a more responsive IT department represents.

    And yet, while we’re automating and simplifying things, the security end of DevOps is doing little for end users. Automating protection of App X is good for the App X team and good for the company, but it means little to the ultimate users of security. We all know security is a burden that users bear in the hopes of protecting the company, but no one is a fan. So maybe you didn’t have self-service password management, and now you do. Great! That helps end users. But most of us were already implementing self-service in an attempt to lift some of the load off of the security and help desk teams by the time DevOps took hold.

    Maybe you’ve implemented SSO as a result of DevOps. Again, good move! Employees spend less time remembering passwords and more time being productive. There’s less stress, too. But again, that was already well along, DevOps or not. And you know what? Employees are still making passwords they can remember, writing down passwords, re-using the same complex password, etc. To make it more difficult to hack, IT has come up with all sorts of strange rules such as, “Password digits, when summed, must be divisible by the square root of pi …” but that does little if the same password is used for LinkedIn (because it is “work-related”) and LinkedIn gets hacked again. And don’t fool yourselves, I know tech-savvy people who do this. Non-technical people are doing it a lot if techies are doing it.

    Which brings us to my suggestion: Your DevSecOps plan should include a password manager budget. There are a ton of them available, they’re cheap enough no matter which one you choose and they will generate complex passwords and then remember them for the user. Give employees password managers, train them a bit on their use, and reduce the chances that their password is the same as the one they used at pleasehackme.com. The investment is small—a few dollars per user for most managers—and choices include vaults that are local or hosted and the ability to set password-generation parameters.

    The only problem with a service-based password manager is ownership of the account after the employee leaves the company, but a policy can clearly delineate when responsibility transfers to the user and arrange for removing them from systems at the same time.

    More secure, less user hassle (true single sign-on, since they only need to know the password to the password management tool) and low cost—this is the heart of DevSecOps. And the investment is small. A bit of cash, a bit of training. What’s not to love?

  • DevOps and Security in a Cloud-Native World

    DevOps and Security in a Cloud-Native World

    DevOps teams have naturally embraced microservices and modern application delivery workflows. But, they may get pushback from risk-averse leadership or feel slowed by security teams who struggle to keep pace. Development teams that play a greater role in guiding their organization’s cloud transformations will ultimately come out ahead.

    These are some of the takeaways from the largest and most globally expansive market research dataset on cloud-native security to date, the “State of Cloud Native Security Report 2020,” from Palo Alto Networks.

    Analyzing the data with a DevOps point of view may help your organization navigate its own transitions.

    Cloud Native Architectures and Security: What it Means for DevOps

    Organizations estimated that, on average, 46% of all workloads are already in the cloud and 95% of respondents expect that number to increase over the next 24 months. This likely means more resources and deployments for DevOps teams, but also means that security needs to meet the needs of these cloud workloads.

    Change is constant in cloud infrastructure

    Most survey respondents (80%) said their company’s cloud infrastructure is constantly evolving. This consistent change stems from companies experimenting and evaluating new cloud offerings, finding best practices and exploring new services.

    But this constant change impacts security teams and their tooling. Both in how they can continuously audit and protect cloud native applications today, as well as how they need to strategize on any anticipated change in the future—75% of respondents worried that cloud threats already outpace security.

    Multi-cloud is the industry standard

    DevOps teams have more options than ever before for running cloud-native apps. Nearly every organization surveyed—90%—confirmed they use more than one cloud platform. And respondents are using a combination of compute architectures: VMs account for 30% of workloads on average, with containers at 24%, CaaS at 21% and PaaS at 22%.

    As DevOps teams take advantage of increasing platform/compute permutations, security teams need both wider and deeper visibility across cloud infrastructure. For some security teams, this has meant more tooling—57% of teams reported using more than five security tools and some up to 11 or more—which may mean a proliferation of workflows, policy engines and dashboards.

    DevOps and security aren’t concerned with any single threat

    They have many that they prioritize differently. When asked for the No. 1 threat, no single answer stood out. Instead, 10 ranked about equally in frequency:

    • Data exposure (13.2%)
    • Malware (12.8%)
    • Application vulnerabilities (10.9%)
    • Weak and broken authentication (10%)
    • Insider threats (9.7%)
    • Credential leakage (9.1%)
    • Insecure APIs (9%)
    • Infrastructure misconfigurations (9%)
    • Application misconfigurations (8.7%)
    • Over-permissioned access and misconfigurations (7.7%)

    This means that DevOps and security teams may sometimes clash about what needs to be the highest priority and how to ensure they are meeting a high level of security.

    While many organizations feel that the diversity of cloud and the speed at which it changes can cause gaps in security, it also suggests there are ways to successfully minimize risks.

    Embedding Security Across the Application Life Cycle

    The survey analyzed the types of actions companies take in their cloud security, then created a ranking based on responses. (Details are available in the report.) Companies with the highest-level preparedness ranking were found to have many of the same habits.

    Many highly prepared organizations (45%) embed security into their DevOps processes and almost as many (41%) integrate security in at least four stages of the development life cycle.

    In addition to shifting security left, these organizations automate many security practices such as configuration monitoring and vulnerability scanning/management, eventually implementing guardrails or quality gates into their regular workflows.

    DevOps teams should work with leadership and security to identify consolidated platforms that can scale to continuously monitor configurations and protect the continuum of compute options discussed above. These types of platforms that can integrate security across the development life cycle are beginning to gain more attention and are becoming increasingly practical solutions.

    Next Steps

    The survey data makes clear that the cloud will continue to evolve as it matures, and it will remain multi-everything. It also suggests there are things DevOps teams can do to help set the model for how cloud is adopted in their organization.

    Security and development teams will need to increase collaboration to identify threats and controls. By shifting left and inserting security to the earliest possible point in the development process, using platforms that integrate across the life cycle, threats or vulnerabilities can be anticipated and their impact reduced.

  • Automation: The Human-Free Zone Approach to Software

    Automation: The Human-Free Zone Approach to Software

    Humans hate repetitive manual tasks. We suck at them—we make mistakes, lose concentration, get bored. Throughout history, humans have instinctually developed automation to keep us away from the hazard-prone, tedious work of these tasks.

    In software, we use configuration management, deployment tools and lean/agile processes born out of factories and the automation principles established there to automate the software factory. Utilizing automation reduces software errors and increases reliability and productivity by allowing the work performed to scale to hundreds and even thousands of systems.

    As we’ve written scripts and functions to help ourselves, we’ve had to implement access control, least privilege, two-person rule and other security principles to secure against the human threat and to prevent catastrophic loss through either a malicious actor, leaked credentials or other type of compromise. And this problem gets more complex and difficult the more automation is involved. However, what if we harness the power of automation to solve our security risks—to remove the human threat mostly or entirely from production by enforcing a single path to production via CI/CD pipelines, building and deploying signed artifacts and system hardening including explicit removal of human/remote access?

    With this, we can validate the chain of custody on all changes to the system while also proving that outside actors cannot make unauthorized changes. This is what we’re looking for when we talk about DevSecOps.

    Automation to the Rescue

    Here are the processes humans should be fully or at least partially removed from to optimize software effectiveness, security and efficiency:

    • Code and pipeline.
    • Artifact deployment.
    • Automated access.

    Code and Pipeline (partial human interaction)

    Let’s start on the left, with our code and pipeline. The rules here are simple and familiar. We start with source code management and the two-person rule. No one individual can write and commit code without approval from someone else. Implementing the two-person rule as well as securing production access ensures that access control happens solely within the pipeline and we have full enforcement of the two-person rule. We can have a full team review along with static code analysis, but the core rule is that no one person has the power to write and commit code, ensuring that a single human cannot be responsible for making a change.

    The code repository is watched by our pipeline with the task of testing, building and verifying a versioned artifact. This artifact is everything in our code at a moment in time. When we think about rollback scenarios, we’re thinking about deploying the previous artifact. This artifact is checksummed so we can attest to its integrity at any point, and we can validate the checksum by pulling the code and building it ourselves.

    Artifact Deployment

    And we need an artifact for not just our application code from development, but also based on what the infrastructure looks like from Operations. This is part of the promise of DevSecOps: Ops writes code that gets checked into repositories just like Development. This allows us to pair our application artifact with our operations artifact. These artifacts together are what we deploy—the system at a moment in time and the application at a moment in time. So, at this point, we’ve established that two humans (at least) have looked at the source code and, once committed, that our pipeline has picked up those changes, performed static code analysis on it and created signed artifacts, ready to be deployed to a test environment. Now that we have our artifacts, we need to deploy them.

    Again, the goal is to not use humans, so after our artifacts are built we must test deployment. The way we ensure security is having the pipeline push the artifacts to a secured artifact store and our systems pull from there as we approve environments to receive the update. This accomplishes two important things: First, by having a push from our pipeline, we again maintain that chain of custody tracing back to source control. Second, we limit which environments are updated by having those systems subscribe to the appropriate artifact stores. The only work humans do here is performing testing and deciding when to promote. The automation actually takes care of the actual promotion work. Now finally, we have the ability to run our artifacts in production.

    Automated Access

    The idea of a continuous delivery pipeline isn’t new and is practiced by many teams today. What we’re going to add to this is a production system that does not have inbound access.

    Because in this design systems pull from the artifact store, the only rule needed is outbound from production to the artifact store. This means you can disable remote management entirely, trusting fully in the chain of custody established in the pipeline. This trust, along with ensuring remote management is disabled, establishes the human-free pipeline. We have shifted user access focus into source code repositories and into the management of the CI/CD pipeline. We have visibility into every stage of the process and eliminated the need for users to have login credentials to production systems. The credential management is also a function of pipeline management, drastically reducing its complexity.

    This is what it means to practice DevSecOps—understanding how automation actually enables the security team to reduce the complexity of our security model and gets security out of the role of blocker and into enabling the business.

  • Upcoming Event: GitLab Commit Virtual 2020

    Upcoming Event: GitLab Commit Virtual 2020

    For the first time ever, GitLab’s annual user conference will take place in a virtual environment on Aug. 26, bringing together DevOps luminaries from around the globe for a free, interactive learning experience.

    GitLab Commit Virtual is a 24-hour virtual event that provides attendees with the opportunity to join DevOps discussions, demos and presentations, and network with thought leaders from the industry’s top companies, such as Microsoft, Google, Hubspot, Forrester and many more.

    Speakers will showcase the power of community and share DevOps best practices through strategy and technology discussions, lessons learned, behind-the-scenes looks at the development life cycle and more.

    The agenda for GitLab Commit Virtual features a mix of topics, including technical sessions, live coding, deep-dives and case studies covering DevSecOps, containers, Kubernetes, CI/CD, open source, all-remote and more.

    The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions by industry leaders.

    This year’s GitLab Commit features more than 40 sessions from some of the most brilliant DevOps experts, including:

    • “DevOps Works! Why Hasn’t Security Kept Up?,” a keynote session by Joni Klippert, StackHawk.
    • “DevSecOps in Government and Highly-Regulated Industries,” a keynote session by Nicolas Chaillan, U.S. Air Force.
    • “Real World DevOps,” by Abel Wang, Microsoft.
    • “Why Your Organization Should Embrace the Community Model,” by Karl Cardenas, State Farm.
    • “Getting Fuzzy: Blurring the Lines of Traditional QA and Security Testing,” by David DeSantos and Sam Kerr, GitLab.
    • “How the U.S. Army Cyber School Created ‘Courseware as Code’ with GitLab,” by Ben Allison, U.S. Army Cyber School.
    • “Measuring DevOps,” by Nathen Harvey and Dina Graves Portman, Google.
    • “How To Create an Equitable and Inclusive Culture That Transcends Physical Walls,” by Eimear Marrinan and Meaghan Williams, HubSpot.

    By visiting the expo hall, attendees will also be able to interact with sponsors, including AWS, Google Cloud, Lightstep, HashiCorp, Red Hat, VMWare Tanzu and WhiteSource.

    Attendees will get a deep dive into how enterprises are transforming DevOps at an organizational level and how they can implement similar practices in their own organization.

    To see the full agenda and to register, please visit the GitLab Commit Virtual website.

  • MuseDev Offers DevOps-Optimized Security Code Analyzer

    MuseDev Offers DevOps-Optimized Security Code Analyzer

    MuseDev today announced it has made available on GitHub under an early access program a code analysis tool dubbed Muse that is designed to surface cybersecurity issues as pull requests are made from the repository.

    Company CEO Stephen Magill said rather than waiting to discover cybersecurity issues after an application is deployed, Muse makes it easier for IT teams to consistently employ best DevSecOps practices.

    There’s general agreement DevOps teams should assume more responsibility for application security as part of any quality assurance process. However, DevOps teams have lacked access to tools that would make it easier to incorporate security analytics within the context of existing application development and deployment workflows, said Magill.

    Muse is also designed to surface cybersecurity issues in a way that makes it easier for developers to comprehend, said Magill. MuseBot automatically analyzes each pull request and delivers bug reports in GitHub as code review comments. In contrast, he noted, code analysis tools employed by cybersecurity teams tend to surface lists of vulnerabilities without providing developers with enough context to remediate or even prioritize.

    Muse is also designed to provide a faster alternative that generates results in about 20 minutes, which means DevOps teams can address issues within a workflow versus waiting for a report from a cybersecurity team, noted Magill.

    Too often code analysis tools will also generate too many false positives, he said. Muse includes a broad set of tools such as ErrorProne, Infer and Pyre for various cloud platforms that are customized and configured to reduce alert noise. Muse also provides access to an open application programming interface (API) that makes the platform fully customizable, Magill added.

    Muse is available as a GitHub app that the company is promising will be free always for open source projects and other public GitHub repositories. Analysis of private repositories is also available at no cost. A self-hosted Enterprise version available for GitHub, Bitbucket and GitLab, scheduled to be generally available by the end of the year, is also available as a private beta. MuseDev is also making available a professional services team to help organizations implement the platform.

    The company itself was spun out of Galois, a research and development firm that specializes in cybersecurity.

    In general, it can cost organizations as much as 10 times more after an application is deployed in a production environment to address cybersecurity issues. Despite widespread awareness of that issue, adoption of best DevSecOps practices within many organizations remains relatively nascent. There’s a lot of interest in DevSecOps as a goal, but few organizations have been able to put the tools that are needed to construct security workflows into the hands of DevOps teams.

    However, as more DevSecOps tools become available, chances are a lot of progress soon will be driven from the bottom up in most organizations rather than from the top down.