devopsy.kinsta.cloud

Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

  • Iterative Adds Experiment Versioning to MLOps Platform

    Iterative Adds Experiment Versioning to MLOps Platform

    Iterative today added an experiment versioning capability to an open source platform for managing machine learning operations (MLOps) using GitOps workflows.

    Dmitry Petrov, Iterative CEO, said the latest version of the Data Versioning Control (DVC) platform makes it simpler to save, compare and reproduce machine learning (ML) experiments at scale without requiring organizations to set up an additional repository to track them. Instead, organizations can store those experiments alongside other software artifacts in a Git repository, he said.

    As a result, IT teams will no longer need to try to keep track of experiments using spreadsheets or notebook tools such as Jupyter, he noted. Organizations that are building AI models for applications constructed using DevOps workflows will also find it easier to comply with a wide range of existing and forthcoming compliance mandates, added Petrov.

    The DVC platform makes use of a Git-like interface to enable organizations to track multiple versions of data sets, models and pipelines across an MLOps workflow. That capability is being extended to make it easier to manage the experiments data science teams create during the construction of an AI model.

    Iterative is at the forefront of an emerging debate over how best to infuse AI models into applications. Providers of platforms used by data science teams are making a case for separate repositories for tracking the artifacts used to construct an AI model. Iterative, on the other hand, is arguing for the use of an AI model build framework that uses the same Git repositories where any other type of software artifact is stored and shared. Iterative’s argument is that, in effect, AI models are just another type of software artifact, noted Petrov.

    In addition to reducing the total cost of building AI models by reducing the number of platforms required, a Git-based approach also makes it simpler for DevOps and data science teams to collaborate because the DevOps team will have more visibility into what AI models will eventually need to be incorporated into an application.

    It may be a while before the development of AI models and applications fully converges. Data science teams today typically have defined their own workflow processes using a wide range of graphical tools. However, as it becomes obvious that almost every application is going to be infused with machine learning and deep learning algorithms to some degree, the need to bridge the current divide between DevOps and data science teams will become more acute.

    In the meantime, DevOps teams should assume that many more AI models are not only on the way but that those models will need to be continuously updated. Each AI model is constructed based on a set of assumptions; however, as more data becomes available, AI models are subject to drift that results in less accuracy over time. Organizations may even determine that an entire AI model needs to be replaced because the business conditions on which assumptions were made are no longer valid. One way or another, the updating and tuning of AI models is likely to soon become just another continuous process being managed via a DevOps workflow.

  • CI/CD Is Still All About Open Source

    CI/CD Is Still All About Open Source

    One of the lessons I’ve learned in my years at the helm of devopsy.kinsta.cloud is that the heart of DevOps is CI/CD. And at the heart of CI/CD is open source. While the names have been changed to protect the innocent (and the obsolete), these lessons are as true today as they ever were. CI/CD is still all about open source.

    When we first started devopsy.kinsta.cloud, folks said that DevOps was just a symptom; CI/CD was the cure. For many of you, that cure was delivered via open source—probably using Jenkins. Jenkins, which itself was a fork of the open source Hudson project, was created by Kohsuke Kawaguchi.

    Jenkins was a CI tool at heart and later morphed into a CI/CD tool. Many people think that this fork in the road may have hurt the continued evolution of continuous delivery in the long term. But that is an argument for another devopsy.kinsta.cloud article (or maybe even a panel discussion at an upcoming DevOps live event).

    Regardless of where you stand on that issue, as an open source project, it is hard to argue with the success of Jenkins. Driving a lot of that success is the Jenkins plug-in architecture. There are literally thousands of plugins that allow Jenkins to work with just about anything. That is the engine that powered Jenkins, yes; but its secret superpower was and is open source.

    That said, Jenkins has grown a bit long in the tooth over the years. It’s not that it doesn’t do what it always did, it’s that what we do and how we do it has changed. Microservices, Kubernetes and even cloud have changed the very fabric of the tapestry in front of which Jenkins sits. The open source community that supports Jenkins should receive enormous credit here: It has tried mightily to keep up with the many changes. 

    Jenkins X sought to bring Jenkins to Kubernetes, for instance. But ultimately, nothing lasts forever and, as it says in the Bible, “For everything there is a season, and a time for every purpose under heaven: A time to be born, and a time to die.” Now, I am not saying Jenkins is dying, but I think its time as the leader of the pack is behind it.

    The good news is there are a host of new CI/CD tools that have risen to fill the vacuum left by Jenkins. Some of them are entirely open source; some are based on open source. Solutions such as Buildkite, Harness, Codefresh, GitLab, GitHub, CircleCI, JFrog and Tekton to name but a few. 

    Another major development has been the rise of GitOps. Weaveworks has led the way in adoption, not to mention coining of the term GitOps itself, but clearly, they are not alone. What these solutions all have in common, though, is open source.

    I used to think it was sort of a chicken-or-the-egg question when it came to CI/CD and open source. But I realize now that it is not. I firmly believe that, if not for open source, CI/CD would not be the force it is today. Make no mistake, it is truly a force. CI/CD has become the dominant method for software development.

    Of course, you could say “Why stop at CI/CD? Open source has become the dominant software development foundation in observability, OS, cloud and so much more!” Yes, I agree—we are living in the open source age. This rising tide may in fact lift all boats, including CI/CD.

    This wave is forcing all vendors to either go entirely open source or at least support open source. What’s more, for the foreseeable future, I don’t see that changing. Open source has also wrought other changes in the market. How software tools, including CI/CD, are distributed and consumed. Who is hiring enterprise software salespeople anymore? Doing large POCs? No, open source has resulted in getting software into the hands of developers and DevOps teams directly and delivering delight. If your product works, they buy it. If it doesn’t work, they won’t, either—and they will let you know, too!

    This meritocracy is another benefit of open source and is helping to speed the development of better, next-gen CI/CD tools in the market. And at the end of the day, we are all better off for that.

  • Is TypeScript the New JavaScript?

    Is TypeScript the New JavaScript?

    While JavaScript is frequently the language of choice for all sizes of frontend and backend applications, it’s not the only option; nor is it necessarily the most efficient or cost-effective. Increasingly, TypeScript is becoming the go-to language for app development—particularly for larger apps. The time- and cost-saving benefits are significant enough that some organizations are even taking projects initially started in JavaScript and migrating them to TypeScript. 

    What is TypeScript?

    While the number of programs written in JavaScript has grown exponentially, the programming language’s ability to express the relationships between different units of code and mitigate coding errors early on hasn’t kept pace. Along with JavaScript’s inconsistent semantics, this makes JavaScript-driven app development difficult to manage at scale.

    Released in 2012, TypeScript was created to address JavaScript’s deficiencies in developing large-scale apps. It’s an open source, strongly typed programming language that builds on JavaScript by adding optional static typing. Types enable structuring and validating code before it’s executed, which is beneficial when developing large apps. They also provide additional information about code, which serves as better documentation for other developers and facilitates collaboration.

    TypeScript is a superset of JavaScript, which means any JS code is also valid TS code—provided the TS configuration is set to be compatible with it. It outputs code in pure JavaScript and allows developers to liberally use JS libraries, tools and frameworks. It runs on Node.js or any browser that supports ECMAScript 3 or higher. It also supports object-oriented programming features. 

    JavaScript Drawbacks

    JavaScript is one of the world’s most popular programming languages and works extremely well for small projects. However, its disadvantages—many of which affect project costs and code delivery time—make a strong case for considering alternatives such as TypeScript, particularly for larger projects.

    Most of these drawbacks have to do with the lack of types and compile-time error checks, making JavaScript less than desirable for server-side code in enterprises and large codebases. The following are just a few of its disadvantages:

    • JavaScript employs dynamic typing, which means scripts can compile even if they contain errors that can prevent them from properly running.
    • Because JavaScript is dynamically typed, it allows one variable to have multiple properties assigned to it. It doesn’t instantly let developers know what a variable can contain. That makes it easy to assign the wrong properties.
    • Since JavaScript is an interpreted language, errors can only be found during runtime. Code needs to run before being tested and validated, so it can take considerable time to find bugs and errors in JavaScript code.
    • To eliminate inaccuracies, it’s necessary to manually verify types and the syntactic correctness of the code. This lengthens development time and extends the delivery cycle to production, increasing development costs.
    • JavaScript code is executed on the client side so it’s viewable to the user. As a result, bugs and oversights have the potential to be exploited for malicious purposes. 
    • Lengthy onboarding of new developers can result because developers must figure out the properties of the structures they’re working with, as well as the data types. While JSDoc can be used for documenting code and annotating types, there’s still the need to synchronize the actual code and documentation. The lack of synchronization, in turn, can mislead developers and complicate the introduction of new, business-requested features.
    • JavaScript is prototype-based, not class-based. It’s not considered a pure object-oriented programming language, although it can follow some object-oriented programming principles.

    The TypeScript Advantage

    TypeScript is a superset of JavaScript. If a developer knows JavaScript, there’s not much of a learning curve to take advantage of the features TypeScript offers that make up for many of JavaScript’s deficiencies—and it can offer additional benefits.

    For example, with JavaScript, variables can start as one property, and then change into an object or a string. These inconsistencies can generate problems that are difficult to resolve in large apps. TypeScript, on the other hand, analyzes the code and tries to determine proper variable types prior to runtime. Once a variable type is assigned, it stays unchanged. TypeScript’s compiler also helps shorten the QA and testing process in later stages of development.

    TypeScript also helps developers quickly figure out the purpose of a variable within the code. It can also suggest available properties in functions, classes or components. Being able to quickly look up a variable is important because it reduces the likelihood of calling the wrong function or accidentally skipping a variable declaration. Any reduction in bugs and errors reduces the time required for fixing those issues and, therefore, reduces overall development time. That gives developers more time to work on app logic and fix errors that can be detrimental to in-app performance and usability. According to a postmortem analysis by Airbnb, 38% of bugs they encountered were preventable with TypeScript after the company adopted it throughout the organization. 

    As a static language, TypeScript performs type checks upon compilation, flagging type errors and helping developers spot mistakes early on in development. Reducing errors when working with large codebases can save hours of development time.

    Clear and readable code is easy to maintain, even for newly onboarded developers. Because TypeScript calls for assigning types, the code instantly becomes easier to work with and understand. In essence, TypeScript code is self-documenting, allowing distributed teams to work much more efficiently. Teams (and individual developers) don’t have to spend inordinate amounts of time familiarizing themselves with a project.

    TypeScript’s integration with editors also makes it much easier to validate the code thanks to context-aware suggestions. TypeScript can determine what methods and properties can be assigned to specific objects, and these suggestions tend to increase developer productivity.

    TypeScript is widely used to automate the deployment of infrastructure and CI/CD pipelines for backend and web applications. Moreover, the client part (for example, when using Angular) and the backend can be written in the same language—TypeScript. This flexibility allows an engineer who knows one programming language to cover all parts of the system.

    Because TypeScript essentially transpiles to JavaScript, migrating existing code to TypeScript is easy and fast. It can typically be accomplished simply by running the compiler and adding typing where it’s not recognized by the language. There’s no need to make changes to the code.

    The benefits of TypeScript have been noticed by developers. TypeScript was used by 78% of the 2020 State of JS respondents, with 93% saying they would use it again. TypeScript continues to grow in popularity. It was voted the second most-loved programming language in the Stack Overflow 2020 Developer survey. 

    TypeScript & AWS: Better Together 

    There’s another compelling reason to consider TypeScript for large-scale app development projects. It’s fully supported by AWS, the leading cloud platform for modern app design and development as noted in Gartner’s Magic Quadrant for Cloud Infrastructure and Platform Services.

    The following services and tools have seamless integration out-of-the-box with TypeScript, enabling you to use this language for a vast number of tasks:

    • AWS CDK provides infrastructure-as-code (IaC) to automatically deploy the entire infrastructure in one click. You can also automate the creation of CI/CD pipelines for the future launch of specific jobs on demand.
    • AWS Lambda allows you to run computation tasks in serverless mode using automatic scaling and an efficient pricing scheme.
    • Amazon EC2, ECS and EKS can cover any of your tasks and provide a wide range of solutions for running apps written in TypeScript—from bare metal servers to complex clusters of hundreds of Docker containers.

    Optimize Your Application Development Projects

    All decisions made during an application development project can impact overall costs and time to market. That includes going with the right programming language and using the most appropriate cloud platform and resources. 

    When approaching an app dev project, a one-size-fits-all approach rarely works. Take the time to define your needs and priorities and select the best resources to deliver the best results.

  • Why Trust and Integrity Are Critical to IoT

    Why Trust and Integrity Are Critical to IoT

    We hear a lot about how the IoT is transforming people’s work and daily lives, but for me, its impact goes deeper. As a Type I diabetic, I depend on data from an IoT device to stay healthy. If I can’t trust my latest blood sugar reading, the results can be catastrophic. Health care use cases like mine represent some of the many examples that underscore the importance of data integrity. Stacey Higgenbotham expressed it perfectly in a recent post: “If a business or consumers can’t trust the data, the IoT fails.”

    The IoT is all about making better, more informed decisions, and data is the foundation that makes those decisions possible. As the IoT gains maturity, we’re seeing its impact across more and more industries and use cases. 

    In agriculture, smart sensors are in widespread use for real-time crop monitoring to help farmers track the state of their products. Tools like motion detectors, light detectors and moisture sensors can be brought together to support predictive analysis and enable smarter, more automated decisions. IoT sensors are also tracking the location and health of livestock to help farmers detect disease outbreaks and isolate animals if needed. 

    Most of us have seen how the IoT has revolutionized the safety and efficiency of the home, providing unprecedented control over appliances, heating and cooling systems, smart metering and lighting. Security cameras, alarm systems and smart locks are strengthening physical security and bringing residents peace of mind. As these smart home systems mature, they are also becoming increasingly integrated, personalized and automated.

    The global pandemic is also helping shape IoT adoption. Forrester predicts that manufacturers, pharmaceutical firms and utilities are increasingly switching to remote experts and technicians for support. To manage and repair their assets without extended downtime and costly travel, these industries have begun connecting previously disconnected machines.

    What do these diverse use cases have in common? Without trusted data from connected sensors and devices, all of them become vulnerable and the decisions they support become questionable. Inaccurate moisture data from a sensor could cause a farmer’s crops to fail. A compromised smart lock could leave a home vulnerable to theft. In a manufacturing environment, inaccurate telemetry from a connected machine could lead to factory floor shutdowns or damaged assets. The positive business outcomes enabled by the IoT all hinge on working with accurate, timely and trusted data.

    Signing Is Key to Strengthening IoT Data Integrity

    Establishing data trust should be top of mind for IoT device manufacturers, and it is imperative that they take steps to ensure that data is not being manipulated in transit or at rest. This protection applies not only to data packets exchanged by the devices and applications but firmware updates and supply chain processes.

    The recent executive order signed by president Biden underscores the need for measures like code signing. Focused on improving the nation’s cybersecurity, the EO presented guidelines and general best practices for federal departments, agencies and contractors. However, its impact is also likely to extend to technology and infrastructure companies. 

    Some of the strongest direction in the EO is intended to improve the security of software as well as supply chains for technology manufacturers. The order establishes baseline security standards for the development of software sold to the government, including requirements for improved visibility into that software and making security data publicly available. The order acknowledges that too many devices and software releases contain vulnerabilities that bad actors could exploit. 

    Effective Code Signing Requires Strong Management 

    Fortunately, a proven solution is available today to help manufacturers ensure data authenticity, confidentiality and trust for their IoT solutions. Best practices like code signing can help manufacturers bake security into each and every stage of their development processes. By applying digital signatures, organizations can assume full control of their development. They can confirm the integrity of their code before it moves further along in the development cycle and is put out in the field for devices and their customers. 

    Code signing is only as effective as the processes and best practices that support its implementation. To make the most of digital signatures, developers and engineers need a holistic approach to management. The signing process should be seamlessly built into their development processes to simplify and ease adoption. 

    A common management platform should enable manufacturers to fully protect private key usage and signatures, as well as monitor and manage access to digital keys. The process should also enable organizations to support granular monitoring of their code signing processes and include historical tools like reporting and auditing for full accountability and compliance. With a process in place to continually sign firmware, software updates and other components that can ensure data integrity in device interactions, manufacturers can be assured that their IoT solutions will work as intended, using data their end customers can trust. 

    There’s no question that as the IoT continues to extend deeper into our business and personal lives, the importance of data integrity is also rising. The stakes will only increase as more systems, processes and life-or-death decisions rely on trusted IoT data. To sustain the soaring growth of IoT use cases and solutions, it’s up to manufacturers to build security into the supply chain. With a strong data foundation underpinning today’s rapid innovation, the potential of the IoT revolution is limitless.

  • WhiteSource Report Finds NPM Vulnerabilities Fixed Fast

    WhiteSource Report Finds NPM Vulnerabilities Fixed Fast

    WhiteSource today published a report that found most of the vulnerabilities that affect node package managers (NPMs), widely employed to deploy JavaScript applications, are addressed long before they are assigned a Common Vulnerabilities and Exposure (CVE) in the National Vulnerability Database (NVD).

    The report, based on an analysis of the vulnerabilities that WhiteSource tracks in its own vulnerability database and revealed at the AWS re:Invent conference, found more than 90% of vulnerabilities in NPM packages are fixed before the vulnerability is published in the NVD.

    Susan St. Clair, director of product management for WhiteSource, said that fact suggests that, overall, the open source community is staying on top of vulnerabilities as they are disclosed rather than waiting for them to be assigned a CVE number.

    The WhiteSource report comes on the heels of a breach of UA-parser.js, a widely employed NPM based on a JavaScript library that detects browser, engine, OS, CPU and device type/model from User-Agent data. Unknown malicious actors found a way to inject malware into the NPM that modified the library. That vulnerability has since been remediated.

    In fact, the WhiteSource report noted 83% of the CVEs assigned to the most widely used versions of vulnerable NPMs could be remediated before the publication of the CVE.

    In the wake of a series of high-profile breaches of software supply chains, there is a lot more focus on how open source software is actually secured. Commercial software products have a distribution list that they typically notify of a security patch. Open source updates, on the other hand, need to be tracked by developers that use that software. The level of attention individual developers might pay to any number of open source updates can vary widely.

    Many developers are also hesitant to immediately update their applications because they are not sure what impact that additional code may have on their application, said St. Clair. For example, their application may have dependencies that are no longer backward compatible with the updated code, she noted.

    Developers also need to determine the degree to which that vulnerability may affect their applications because they often don’t use every component of an open source library, so the fix being offered may not be required.

    Open source project maintainers often depend on their community to help uncover vulnerabilities and create the fixes as quickly as possible. When a vulnerability is detected in an open source library, the more common practice is to report it to the NVD even after the fix for that issue has been made available.

    In general, St. Clair noted the most important thing for the open source community to remember is to remain proactive when it comes to tracking vulnerabilities and then implementing DevSecOps best practices. The one thing that is certain is that a wide range of malicious actors also are tracking those vulnerabilities closely. It’s not uncommon to see a wave of exploits being created once a vulnerability is disclosed via the NVD.

    The challenge, of course, is that the more open source software that is employed, the more difficult it becomes for individual developers to stay on top of every vulnerability in an application portfolio that only continues to grow. On the plus side, vendors have pledged more than $10 million to help better secure open source software. Hopefully, the return on that investment will become apparent sooner than later.

  • WhiteSource Adds SBOM Tool That Lists Vulnerabilities

    WhiteSource Adds SBOM Tool That Lists Vulnerabilities

    WhiteSource has added a software bill of materials (SBOM) tool to its portfolio that, in addition to capturing the components of an application, also surfaces vulnerabilities that should be addressed.

    Many organizations are becoming more rigorous about making sure SBOM are attached to every software development initiative in the wake of an executive order issued by the Biden administration that requires federal agencies to employ them. While not every organization builds applications for federal agencies, the fact that the federal government is requiring them in the wake of a series of high-profile breaches has led other organizations to review their software supply chain processes.

    An SBOM facilitates those reviews by making available a formal, machine-readable inventory of software components and dependencies that can be used to track their supply chain relationships and identify dependencies and hierarchical relationships.

    Ori Bach, executive vice president for product at WhiteSource, said WhiteSource SBOM takes the concept a step further by also identifying open source libraries. It will also automatically update the SBOM when changes are made to make it easier to identify unintentional or malicious content being installed during application builds.

    Finally, WhiteSource SBOM also provides remediation guidance that ensures updates won’t break the build.

    Bach said it’s already apparent cybercriminals have significantly increased their effort to compromise supply chains as part of an effort to compromise as many downstream applications as possible. In many cases, cybercriminals are now specifically targeting open source projects that create software that tends to be employed across a wide range of use cases.

    An SBOM in and of itself doesn’t make applications more secure. However, it can provide visibility into the components of an application that can then be used to inform DevSecOps best practices, which organizations are implementing more broadly as responsibility for application security continues to shift left toward developers.

    There are two primary specifications that organizations can use to create an SBOM. The Software Package Data Exchange (SPDX) specification is an open standard for communicating SBOM information including components, licenses, copyrights, and security references. Defined by the Linux Foundation, SPDX is now recognized as the ISO/IEC 5962:2021 international standard. The second is the Software Identification (SWID) format that is today widely used by publishers of commercial software.

    Regardless of the format used to construct the SBOM, Bach said there’s an opportunity to more closely align the increased visibility it enables with the application security goals of the organization building the application.

    The primary reason SBOMs are not as widely used as they might be by now has as much to do with inertia as it does with technology. However, as organizations start to expect an SBOM to be made available, it’s clear application developers and builders will need to find a way to automate the SBOM process as applications are continuously updated. The challenge, of course, is that applications are now being updated with greater frequency—thanks mainly to widespread adoption of DevOps best practices—that now need to be integrated with any tool for creating and maintaining an SBOM.

  • ServiceNow Acquires DotWalk to Gain AI for App Testing

    ServiceNow Acquires DotWalk to Gain AI for App Testing

    ServiceNow today revealed it has acquired DotWalk to gain an artificial intelligence (AI)-infused application testing capability that runs natively on its software-as-a-service (SaaS) platform.

    Joe Davis, senior vice president for platform engineering at ServiceNow, said that testing capability will be made available free of charge to all organizations that build custom applications on the company’s platform.

    The number of custom applications being built on the ServiceNow platform has risen sharply since the start of the pandemic. Many organizations have taken advantage of the low-code tools provided by ServiceNow to build a range of applications that use the company’s SaaS applications as a foundation. That approach enables them to more quickly build applications that drive a wide range of digital business transformation initiatives.

    Davis said ServiceNow is committed to enabling organizations to improve the quality of those applications using a DotWalk testing capability that eliminates the need for developers to build and run tests themselves or for organizations to hire dedicated application testing teams.

    ServiceNow

    ServiceNow decided to acquire DotWalk because the company built a testing platform using machine learning algorithms specifically for the ServiceNow platform, noted Davis. The DotWalk tools also analyze logs in the background to identify and validate error sources that can arise during any application upgrade process.

    While there are a large number of professional developers that build applications on the ServiceNow platform, the company is also trying to encourage more so-called citizen developers to build applications. The challenge is many of the end users building applications lack an appreciation for design, security and what it takes to make sure an application scales as more users employ it. Testing tools infused with AI should make it easier for developers, regardless of experience, to build enterprise-class applications.

    Of course, professional developers will also benefit from AI-infused testing tools. Many developers have a tendency to cut short the application development process as they rush to meet application delivery deadlines. The end result, however, is that an application must be updated almost immediately after it has been deployed in a production environment. Testing tools that make use of AI will enable professional developers to more easily run tests they don’t have to build and then maintain, said Davis.

    One way or another, the number of custom applications built on SaaS platforms will increase as organizations digitize more processes. In the last year, more organizations have become adept at extending these platforms using a wide range of low-code tools that automate many aspects of application development. A significant percentage of those organizations are now also adopting DevOps best practices to better manage the pace at which those applications are developed and deployed.

    In the meantime, it’s too early to say precisely how AI will transform application testing. However, one thing that is certain is that even as the number of custom apps grows, applications will be more thoroughly tested before being deployed in a production environment.

  • DevOps Teams Struggling to Keep Secrets

    DevOps Teams Struggling to Keep Secrets

    A growing number of organizations are suffering security incidents related to exposed secrets in DevOps CI/CD pipelines, according to a recent ThycoticCentrify report.

    The study paints a troubling picture: Only 5% of survey respondents said most of their development teams use the same secrets management processes and tools.

    The incidents run the gamut, from secrets published in the clear in public cloud code repositories to insecure third-party code to vulnerabilities in the organization’s own code or configurations.

    The problem is often made worse by security teams not knowing what to protect because development teams have their own cloud infrastructure or the ability to create internet-facing applications directly without security teams’ knowledge.

    “The reason why we see so many security incidents related to exposed secrets in DevOps is that using hardcoded passwords and keys is the easy path to getting things to work,” said Joseph Carson, chief security scientist and Advisory CISO at ThycoticCentrify. “We need to make it just as easy for DevOps to use secrets vaults so even when secrets get compromised they are no longer usable, valid or expired.”

    Carson said moving away from persistent privileges to just-in-time, on-demand privileges will reduce these types of misconfigurations and attacks.

    “Unfortunately, many developers continue to use hardcoded passwords or static keys that, when compromised, allow an attacker to gain control of the application resulting in either data exposure, ability to change the application configuration or move laterally around the network,” he added.

    John Bambenek, principal threat hunter at Netenrich, said the fundamental problem is that when organizations go to agile and DevOps, they remove all friction to moving code quickly—and that almost always includes removing security.

    “That means security is inherently reactive instead of being embedded into engineering, and that’s assuming security even knows what to protect in the first place,” he said. “It’s the natural consequence of removing security from the equation and expecting that it’ll just work on the backend. That approach hasn’t worked for decades; a JIRA board isn’t going to suddenly fix that problem.”

    From Carson’s perspective, secrets management is the ability to move away from hardcoded passwords or static keys to just-in-time privileges or one-time-use passwords so even when comprised they cannot be used.

    “Many privileged access management solutions that protected privileged access for years have extended functionality to developers to help move the value into DevOps so they can manage credentials for applications, databases, CI/CD tools and services without causing friction in the development process,” he said.

    Approaches like privileged access security helps enable API-as-a-service and provides instant availability of secrets, SSH keys, certificates, API keys and tokens.

    Secrets Management

    Bambenek added the problem isn’t choosing a secrets management process or tool, but rather that they aren’t in place at all.

    “Pick something that will keep keys and secrets out of public cloud repositories that developers will use that allows for quick and easy rotation of keys as the need arises,” he said. “The most important thing is that it’s the same tool everywhere that operates in a near-invisible process for developers. Four decades of software vulnerabilities have taught me that if you rely on the developers to do the secure thing, you’ll consistently be disappointed.”

    One Wrong Step

    Davis McCarthy, principal security researcher at Valtix, pointed out developers are not security practitioners by trade.
    “Developers are building new ideas, and no good idea comes without experimentation,” he said. “Experimenting with a new technology stack may lead to misconfigurations that unintentionally expose data.”

    McCarthy said shared SSH keys between users create a larger attack surface, and users will store secrets differently creating multiple attack vectors.

    If one user’s endpoint becomes compromised and their SSH keys are exfiltrated, it’s difficult to know what the first mitigation steps are. Between insider threats and malware, the wrong step could lead to a breach.

    “Whereas a software engineer may hold great knowledge of secure coding methodologies, web application attacks and encryption, they are still focused on executing their craft,” he said. “Organizations that do not build security into the development life cycle create a systemic risk that leads to failures in best practices.”

    McCarthy added organizations can centralize and embed secrets management into the tools already in use in CI/CD pipelines by creating an inventory, auditing it and frequently rotating secrets to sensitive environments.

    Bambenek said the short answer is to make sure the infrastructure of CI/CD pipelines is centrally managed and controlled without the ability of engineering teams to ‘roll their own.’

    “No security control will remain intact if someone can pick their own tools without any real governance,” he said. “CI/CD processes don’t require engineering teams to manage the backend of the deployment pipeline which means someone can ensure those functions are in place to begin with.”

  • Rethinking Programmer Education for Today’s Coders

    Rethinking Programmer Education for Today’s Coders

    The proliferation of low-code and no-code applications are changing the landscape for software. In the past decade, growth in these areas has empowered employees to generate solutions at the speed of a digital world, regardless of their technical background.

    This raises several questions: What kind of programmers do businesses really need? Should they still rely on programmers formally trained at four-year universities—what you might call “white-collar” programmers? Or, instead, are blue-collar programmers with self-taught skills or those who learned from a bootcamp more valuable? What will get organizations the right mix of programming skills?

    The short answer is that all programmers can be of great value. In general, blue-collar programmers, after all, connect things within the computing environment, while white-collar programmers create the things that are connected. The essence of low-code is that it allows more people to connect things and use their creativity to become more productive. But it doesn’t eliminate the need for professional programming and tools at its foundation.

    At their core, low-code and no-code are about democratization. They allow people without technical skills to work creatively in ways that essentially make everyone a programmer. A parallel from an earlier computing generation is the Excel spreadsheet, which lets people with no programming background perform computational tasks and eventually work their way up from simple formatting to full-fledged programming. But at some point, polished programming skills are still necessary, no matter how easy no-code or low-code can make some of those elements.

    In the breakneck pace of cloud-based computing environments with new services constantly being developed and deployed to the edge, it’s worth considering the distinctions between the white- and blue-collar programmers and what kinds of education are appropriate for each.

    Four-Year Colleges Vs. Boot Camps

    A career as a programmer can seem intimidating for onlookers. This is particularly true when these jobs involve complex languages such as C++ and Java, which are often used in large projects that can take years to develop and involve millions of lines of code. Some of that is still true, but the evolution of programming over the years toward languages that require less code, such as Python, and to domain-specific languages (DSLs), has also started to lower the barriers to entry for programming.

    It’s true that you’ve never needed a four-year computer science degree to be a programmer. In fact, many that have dropped out of college—or never attended at all—have made significant contributions to the industry. However, universities do provide a foundation in theory and algorithms that have always served programmers well and enable them to branch out into new areas, such as artificial intelligence or other disciplines, such as bioinformatics. Coding bootcamps, for their part, can provide intensive training on DSLs or frameworks like Rails or React.js that can benefit companies’ plans, giving blue-collar programmers the practical skills that white-collar programmers may not have. They also attract career-changing attendees with four-year degrees in other subjects, including the humanities and the sciences, which brings badly needed new ways of thinking into the profession.

    While each method is valid, both four-year institutions and bootcamps also have their shortcomings. Universities delve deep into software development theory but often don’t emphasize critical aspects of doing the job, such as teamwork, testing and agile processes. Nor do they focus much on core areas of businesses today, like cloud computing. Boot camps, by targeting specific areas and emerging technologies and languages, can help people get internships or entry-level jobs, but don’t provide a broader theoretical knowledge of programming. And they can be hit-or-miss, with some of them using sketchy practices for payments and job placement.

    The inherent weaknesses in both white- and blue-collar training can be addressed through apprenticeships and internships, but only to a point. The question remains: Who will train low-code programmers on modern development and coding practices? A lot of companies throw around terms like Agile and CI/CD, but they’re often just new labels on old, inefficient practices. Companies will need white-collar programmers to bring blue-collar programmers up to speed.

    Programming for the Masses

    No-code software is a great enabler, allowing people with no formal education or experience to become proficient in a programming environment. On the other hand, for people who do have formal training—whether a formal education or boot camp experience—low-code simplifies their work, leaving time to focus on more complex projects. But programmer or not, users of no-code and low-code solutions need to understand more than just deployment and testing if they want their software to be reliable and useful.

    Professional developers can make a difference by creating and maintaining the pipelines used to build, test, archive and deploy low-code software; they will need to build new tools to accommodate low-code frameworks. And while familiarizing themselves with current development techniques, they could become the teachers of essential computing practices that don’t involve coding.

    A cooperative, productive relationship between white-collar and blue-collar programmers is essential to moving forward with software development, as it will allow both to continue acquiring new skills and experience outside of low-code, which is only a product of programming, no matter how ubiquitous it may be.

    Making the Connection

    Today, we’re entering a business world where practically everyone will need to code, making low-code and no-code frameworks necessary, especially for users without formal training. However, the importance of professional programmers will remain, too.

    We’re likely to see a proliferation of DSLs created to solve specific problems, which will eventually evolve toward general-purpose programming languages. Programmers will need to build web frameworks, cloud capabilities and more, including everything from web widgets to the high-level tools that let users work. That may be the only way we can begin to meet the demand for more people who can program as more devices come online, more connections are made and the world becomes increasingly reliant on automation.

  • Cortex Expands Microservices Catalog to Improve Collaboration

    Cortex Expands Microservices Catalog to Improve Collaboration

    Cortex, a provider of a catalog for tracking the ownership of microservices, today announced it has added a service creation capability that enables developers to use templates to scaffold new services in five minutes.

    In addition, the company has added a Cortex Teams offering that improves collaboration across teams of developers working on interdependent microservices.

    Fresh from raising an additional $2.5 million in funding, Cortex claimed it has increased its customer base by a factor of 10 since initially launching last May. Those customers include Rappi, Grammarly and 8×8.

    Cortex CTO Ganesh Datta said the company’s microservices catalog makes it simpler for teams of developers, DevOps engineers and security professionals to collaborate at a time when software development is becoming more complex. While microservices-based applications are easier to update and generally more resilient than monolithic applications, composing an application based on interdependent microservices created by different development teams can be more challenging to build and maintain.

    In some cases, organizations can even discover that different teams within their organization have built redundant microservices. Part of the reason that occurs is many IT teams still rely on spreadsheets to keep track of what microservices are being built and which ones are already deployed in a production environment.

    Cortex, in contrast, automatically imports data residing in developer tools to surface who within an organization is responsible for maintaining which microservices. A Cortex dashboard also enables DevOps teams to see which developers are on-call in the event of an unexpected incident as well as monitor and track the latency rate microservices are experiencing and which vulnerabilities have yet to be remediated.

    At the core of the platform is Cortex Query Language (CQL), a domain-specific language that allows DevOps teams to define granular rules that can be applied to, for example, on-call rotations, security vulnerabilities, package versions, service level objectives (SLOs) and the overall health of the microservice. Engineers can employ code in the form of YAML files to set reliability standards across teams and types of services.

    Grades can also be assigned to specific microservices based on associated metrics. That approach allows DevOps teams to apply gamification techniques using a scorecard to encourage developers to continuously improve their microservices. That capability makes it apparent to other developers which microservices can be most reliably employed.

    It may be a while before microservices-based applications dominate the enterprise landscape. Monolithic applications will be running in production environments well into the next decade. However, many of those monolithic applications are essentially being converted into a larger microservice that other applications can invoke via application programming interfaces (APIs) before being eventually being re-engineered into a set of logically connected microservices.

    The one thing that is clear, however, is that as the number of microservices expands, it becomes more difficult to determine precisely what capabilities are already available to highly distributed application development teams.