Category: Features

  • Predict 2021: What Does the “New Normal” Look Like for DevOps?

    Predict 2021: What Does the “New Normal” Look Like for DevOps?

    2020 has been pretty tough for most of us, no doubt. It has been a year of uncertainties and unexpected changes, mainly due to the COVID-19 pandemic. However, the future is bright and 2021 is full of possibilities. What does next year have in store for us? At Predict 2021 Virtual Summit, taking place Jan. 21-22 at 10 a.m. ET, top industry leaders will share their speculations on what the future holds in the realms of DevOps, cybersecurity, digital transformation, cloud native and IT.

    Predict 2021 is a free, multi-track virtual event featuring a conference lobby, presentation theater, expo hall and more. Attendees will be able to interact with sponsors and peers, watch videos and download more information. It will be a great opportunity for networking and learning about what the “new normal” will look like for DevOps.

    Are you interested in sharing some of your predictions for the upcoming year? The call for speakers is currently open — for a limited time, as we are starting to get swamped with submissions from folks who want to share predictions and thoughts on the new year and beyond. Now is your chance to prove your special ability to foresee the future of IT.

    We invite all analysts, practitioners, venture capitalists and thought leaders to share their insights, best guesses and predictions for 2021. Abstracts must be submitted through this form by Dec. 11.

    For more information, please visit the Predict 2021 website. Sponsorship opportunities are also available. Predict 2021 sponsors include CircleCI, Harness, WhiteSource and more. For sponsorship opportunities please contact Deb Schalm at deb@mediaops.com.

  • Announcing the 2020 DevOps Dozen² Awards Finalists

    Announcing the 2020 DevOps Dozen² Awards Finalists

    We are excited to announce the 2020 DevOps Dozen² Awards finalists. For six years in a row, we have been honoring the most outstanding leaders in the DevOps community. This year, we decided to expand our awards program to include two different sections: DevOps Dozen Tools and Services Awards and DevOps Dozen Community Awards.

    Those who made it to the finals have demonstrated exceptional performance and service to the community during the past year. Finalists were picked based on most nominations. Congratulations to each and every one of the finalists in the 24 categories. It is quite an accomplishment to make it this far.

    Without further ado, here are the finalists for the 2020 DevOps Dozen² Awards.

    DevOps Dozen Community Awards

    1. Best DevOps Industry Implementation
    1. Best DevOps Survey/Analysis/Research
    1. Best DevOps Related Video Series (Video)
    1. Best DevOps.com Podcast of the Series (Audio Only) of the Year
    1. Best DevOps Books / eBook of the Year
    1. Top DevOps Evangelist
    1. Best DevOps Transformation (Non-Vendor)
    1. Best DevOps Virtual Event of the Year
    1. Most Innovative DevOps Open Source Project
    1. DevOps Executive of the Year
    1. Best DevOps Presentation of the Year
    1. Best DevOps.com Article of the Year

    DevOps Dozen Tools and Services Awards

    1. Best End to End DevOps Tool/Service
    1. Best DevOps Repo/GitOps Tool/Service
    1. Best CI/CD Tool
    1. Best Value Stream Management Tool
    1. Best Observability Solution
    1. Best DevSecOps Solution
    1. Best Testing Service/Tool
    1. Best Kubernetes Platform/Service
    1. Best Cloud Native Security Solution/Service
    1. Best DevOps for Mainframe Solution
    1. Best DevOps for DataOps/Database Solution
    1. Best New DevOps Tool/Service Provider

    Finalists will receive a badge to display on their website and social media with a link to the voting/survey site.

    Voting for the winners in all 24 categories is now officially open to the public. Click here to vote for the leaders, tools and companies you think are truly deserving of an award for their exceptional service to the DevOps community. Winners will be chosen from among the finalists with general public voting being weighted for 40% of the final total and our judges selections for 60% of the weighted total. The deadline for public voting and judges submissions is Jan. 8, 2021.

    Winners will be announced at Predict 2021 Virtual Summit and will receive both digital and physical trophies and badges celebrating their achievements.

    Thanks to everyone who voted and nominated candidates. Good luck to all the finalists!

  • The DevOps Long Tail of Salesforce’s Slack Buy

    The DevOps Long Tail of Salesforce’s Slack Buy

    While most of the focus on the acquisition of Slack this week by Salesforce for $27.7 billion clearly revolves around digital business transformation initiatives, the implications of the deal for DevOps teams that have been employing Slack to collaborate for years is significant.

    Salesforce owns both Heroku and Force.com in addition to providing developers with a set of low-code Lightning tools for building applications on top of software-as-a-service (SaaS) applications built by Salesforce.

    During a conference call with analysts this week, Salesforce CEO Marc Benioff made it clear most of the initial focus will be on tightening integration between Slack and the company’s broad portfolio of customer relationship management, marketing, analytics and artificial intelligence software. However, Slack first gained traction as a collaboration service that DevOps teams employed to share updates and notifications. Many DevOps teams still employ Slack for that purpose and it’s only a matter of time before all the units that make up Salesforce tighten integration with Slack.

    It’s not clear to what degree that integration might convince DevOps teams to either stay with or switch to one of the several platform-as-a-service (PaaS) environments that Salesforce makes available. However, the Lightning PaaS that Salesforce provides for organizations that want to extend the company’s SaaS applications has been gaining significant traction. Rather than writing entire applications from the ground up, the path of least digital business transformation resistance for many organizations is to employ low-code tools such as Lightning to extend existing SaaS applications.

    Salesforce also own MuleSoft, which it positions as a platform for integrating both SaaS and on-premises applications to further those digital business transformation initiatives.

    That approach has gained significant traction in the last six months as organizations have expanded reliance on SaaS applications to enable employees to more easily work from home to help combat the COVID-19 pandemic. For its most recent third quarter, Salesforce posted revenues of $5.42 billion, an increase of 20% year-over-year. Benioff said the company is now lifting its future guidance to slightly exceed pre-pandemic levels. Salesforce is projecting fiscal 2021 revenue at the end of its fourth quarter will total $21.11 billion. Revenue guidance for fiscal 2022 has been raised to $25.5 billion.

    Most of the custom applications being built on top of Salesforce platforms are constructed by professional developers. That shift toward employing Salesforce SaaS applications as a platform has created demand for DevOps platforms from providers such as Copado and Gearset. Most recently, Gearset has begun offering free training to encourage the adoption of best DevOps practices among developers of applications based on the Salesforce platform.

    Benioff said the first fruits of the acquisition of Slack will manifest themselves next year. In the meantime, DevOps teams that have standardized on Slack for collaboration should expect to be hearing a lot more about Salesforce tools and platforms on a Slack channel near them.

    Of course, none of this is lost on Microsoft, which is similarly moving to incorporate Microsoft Teams within DevOps workflows. It will be up to each individual DevOps team to decide which approach to collaboration makes the most sense from here.

  • DevSecOps Implementation: Dynamic Scans

    DevSecOps Implementation: Dynamic Scans

    This is the third installment in this series on DevSecOps. Read the first installment, on static analysis, here and the second installment, on source composition analysis, here.

    One weakness of static analysis is its failure to account for environment and use. Running static analysis on a code base as the only check before production deployment is akin to looking at the engine of a VW Golf before assembly and pronouncing the vehicle fit to use. The way a vehicle runs after assembly, and the way it is—or, more precisely for dynamic scans, could be—used, matter to any product. That is where dynamic scans come in.

    Exercising the product as it runs is a big deal, and that is what dynamic scanning attempts to do. Automating the testing of applications by exercising inputs and watching the results, dynamic scans can detect a variety of issues that static analysis simply cannot. These tools are the source of a lot of the noise in DevSecOps because they’re testing a variety of scenarios with each run, and things that a dynamic scan sees as vulnerabilities might very well be known to not be a risk at all by the dev team. As with static analysis, this has been improving over time, and they’re well worth a look at this point.

    The best use for these tools is as gateways—before going to test, in test and before going to production, set a policy for promotion requirements and then run dynamic scans to determine if the application meets that policy, needs remediation or needs approval to go live with possible issues known.

    With all of that said, here is a starter list of things to look for when considering using dynamic scans:

    • Production Safe: These tools run tests that try a documented vulnerability to see how the application responds. The thing is, if you’re not very careful, this can cause serious problems in production. Since long-term the trend is to eliminate a pure test environment for all but the most stability-conscious organizations, knowing that the product you choose can run in prod without causing outages is an important step.
    • Vulnerabilities Tested: Most vendors offer a list of what they look for. Compare these lists to your organization’s needs and other vendor’s lists. Since choosing a product is unique to each org, I don’t have much in the way of buying advice, but here I will say if the product does not support at least the OWASP top 10, look elsewhere, simply because OWASP is both a recipe for you to prevent attacks and a handy list of easy vulnerabilities for attackers to look for. All of the vendors we looked at for our ASG work do support OWASP, so this might be non-advice.
    • Integration: Dynamic scans need to be run after the product is fully assembled. This is not to say complete, but the various pieces need to be together—the scans generally look at an application, not pieces thereof. This means they can be spawned at any point after build—or, more specifically, after post-build deployment to dev/test/prod. Make certain there is a place in the toolchain to call the scanner from and proper gateways to suit your organization’s needs. Part of that evaluation is how the application is kicked off: Can your build tool call it directly? Is it deeply integrated into your chosen environment, or will you have to do work?
    • Reporting and Gating: What level of reporting is available: Can dynamic reports and static reports be integrated to show that a potential problem reported by static scan is found to actually be a problem by the dynamic scan? Can an overall status report be found (à la C-level dashboards) to show the security posture of a given application? Can alerts be configured for apps that fail certain tests (so you can make informed decisions before going to production, for example)?
    • RBAC: This is applicable to all scanning, but I’ve chosen to include it here because for dynamic (and interactive), it’s a bit more important. Can you limit what an individual can see/do? In the end, dynamic scans are reporting on actual vulnerabilities in your codebase—only those who need to know to fix the issue should be able to see it; others should just see pass/fail overall for the app, not a list of known vulnerabilities in the app. The ability to run these scans should likewise be limited. Who/when is a corporate decision that is as much policy and process as it is the chosen tool, but if the scanner doesn’t support that policy, enforcement becomes more difficult.

    When you get to interactive scanning, it is time to consider how security issues traditionally have been handled versus how they should be moving forward. Most organizations hold security issues separate from other application development issues. It is time for that to end—and indeed, some organizations ended this process long ago, but too many are hanging on to the past. Security vulnerabilities that can result in a risk to the organization need to be run through the system as high-priority bugs. Because they are. We used to think that something making the UI look bad for 5% of customers was more important than a security issue impacting no one. A truly global internet and the rise of automation even among attackers make this a silly stance to take. No one is impacted by security issues at this second, but sometime in the next minute, everyone might be impacted. It’s like saying you don’t need scalability for Black Friday because the servers are handling traffic well right now (written in early November). The issues that dynamic scanners alert on are generally real (removal of false positives has come a long way in the dynamic space) and generally dangerous. If your scan tool can find it, assume attackers’ scan tools can, too.

    As with the other installments, I’ll thank you all for keeping the lights on in a really topsy-turvy IT environment—you are doing us all a service—and mention that all of your hard work is at risk if security at your organization isn’t taken seriously. We quickly identified the threat from the sudden opening of millions of RDP ports on the public internet, and most of you took steps to secure your own. Keep it going. Make certain the apps you are developing and deploying are as safe as you can make them. And keep kicking rear—you are the rock that’s keeping the suddenly dispersed company clipping along.

  • To Accelerate Digital Transformation, Accelerate Data Transformation

    To Accelerate Digital Transformation, Accelerate Data Transformation

    Successful digital transformations are not possible without successful data transformation. After all, it’s data—and the ability to analyze that data—about an organization’s customers, employees, infrastructure, market dynamics, supply chain, business-technology systems and more that make digital transformation possible.

    However, last year Gartner said that “information as an asset” is still in its infancy. “Data and analytics are the key accelerant of an organization’s digitization and transformation efforts. Yet today, fewer than 50% of documented corporate strategies mention data and analytics as fundamental components for delivering enterprise value,” the analyst firm wrote in its report, “Why Data and Analytics Are Key to Digital Transformation.”

    Further, Gartner predicts change is coming and quickly: Gartner says that 90% of corporate strategies will unequivocally list information as a critical enterprise asset and analytics as an essential competency within two years.

    Getting there and being successful with data and data analytics won’t come without significant challenges.

    According to a survey released by IDG (sponsored by Matillion, a cloud data transformation provider for cloud data warehouses), the challenges are steep. The survey polled more than 200 IT, data science and data engineering professionals at North American organizations with at least 1,000 employees.

    What are the challenges enterprises are facing? According to the survey results, 47% said data control issues are the biggest challenge to data analytics projects. In contrast, other top challenges indicated are lack of a scalable, reliable technology platform to process large data sets (45%), having too many manual processes (38%) and challenges cleansing and preparing data (36%). Additionally, 40% cited a lack of visibility and control of data silos as a challenge when collaborating with business users.

    With that, it’s not surprising to learn that it takes on average one week to pull together and prepare data for useful analysis, and 45% of all time spent on data analytics initiatives is consumed by data preparation. About 60% said they lack the scalability and flexibility they need when preparing data for analysis.

    It was almost unanimous when it came to the number of companies that sought ways to accelerate their approaches to data analysis improvement.

    So how are enterprises accelerating their efforts to improve data analysis to better power their digital transformations? Respondents said data portability (57%), ease of onboarding (57%) and cost-effectiveness (52%) are the top features of an analytics platform that can help them move past current obstacles. The IT professionals surveyed favored user-friendly (50%) and easier connections to data sources (50%) as top features; however, data engineers, data scientists, data architects and others cited time-to-value (57%) and ability to provide self-service (51%) as essential capabilities.

    A sizeable portion of those surveyed indicated they are already on their way, adopting the technologies and processes they need to improve their ability to analyze their data for better decision-making rapidly. According to the survey results, 38% are already using cloud data warehouses. And in the future, 43% said they expect to have all of their data in the cloud, with 57% planning to use both cloud and on-premises data strategies.

    Those that master their data analytics more rapidly may enjoy an early mover advantage. “A company’s ability to compete in the emerging digital economy will require faster-paced, forward-looking decisions,” said Douglas Laney, distinguished VP analyst at Gartner. “Data and analytics leaders need to assert themselves into corporate strategic planning to ensure that data and analytics competencies are incorporated within the highest-level public-facing enterprise plans.”

  • The Future of Application Development

    The Future of Application Development

    What lies ahead for application development? Can we look forward to a less hierarchical system?

    The current state of application development has an often overlooked problem: It’s inaccessible.

    Top tier companies such as Google, Microsoft, Apple and Facebook are at a major advantage. With their large capital, they can invest in innovative development tools and round up extensive workforces of leading talent to use them—which matters, especially amid an ongoing developer drought. Meanwhile, companies lacking these privileges must make do with a leaner toolset and smaller, less cherry-picked workforce—which is not to say that they don’t make smart, creative use of what’s available to them, but that they deserve to play ball on a more equal playing field.

    Unfortunately, the pandemic compounded this issue, at times bringing even greater advantages to the tech giants. To overcome what some consider a trend of software elitism, efforts have been made to accelerate the pace of application architecture for all. Employing no-code and low-code tools, for example, could help the smaller guys compete. However, as Robson Grieve, CMO of enterprise software company OutSystems sees it, “these latest approaches are mostly point solutions solving a limited set of problems.”

    I recently invited Grieve to share more of his take on this issue and how he envisions a future of application development that works inclusively for a wider set of companies.

    Application Development: The Other 99%

    “It’s frustrating that the best, most advanced development tools have traditionally only been accessible to the largest, richest companies,” said Grieve. “Everyone else suffers with ballooning backlogs and struggles to take advantage of the latest, greatest technologies.”

    While it may sound like a platform out of a Bernie Sanders speech, recognizing the advantages of the top 1% in the application development world brings up a valid line of questioning as to whether maintaining this status quo is really how we want to go forward. After all, wouldn’t it be better if more companies had access to the best technologies? Wouldn’t we all benefit from that?

    Creating a More Equal Playing Field in Application Development

    Luckily, we are already feeling the winds change in this department, as top tier companies are beginning to lose their stronghold on the crème de la crème of development tools. What’s beginning to change, Grieve believes, is “access to the most sophisticated tools and advanced technologies are being democratized … sophisticated, feature-rich, beautiful, and mission-critical applications are no longer the sole domain of the elites.”

    How is this being realized? In many ways, it’s coming from the makers of the development tools themselves, who are bringing careful thought and creativity to tool design. Some of the strongest approaches in Grieve’s eyes include the following:

    • Holistic approaches that streamline the most critical innovations into single, integrated platforms.
    • Low-code approaches that help accelerate development while retaining the power and expressiveness of traditional code.
    • Platform approaches that offer design, development, deployment, monitoring and management capabilities in one place.
    • Multi-functional approaches that serve a diverse team, support the full DevOps life cycle and, in effect, improve productivity and collaboration. For example, platforms crafted to serve the unique needs of UI/UX experts, business analysts, professional developers and architects.
    • Automated approaches that allow applications to be continuously updated and seamlessly modified once they’ve been deployed, using an AI-powered automation layer that underpins the tool, managing application dependencies and providing self-healing capabilities to ensure that regardless of what changes are made, the tool never breaks.

    One thing that stands out here, according to Grieve, is the idea that broad, multi-functional development platforms reign supreme. As Grieve noted, “the most valuable tools are the ones that solve the broadest set of problems.” In general, approaches that keep in mind security, scalability, reliability and availability will be robust solutions for diverse teams, both large and small. A bonus is if the tool is visually appealing and model-driven for the best ease of usability and user experience.

    All for One, and One for All

    The issue of software elitism is one problem that can be seen as a clear opportunity, and that opportunity is not being missed among the smartest makers of development tools. As Grieve said, “Modern application platforms have the potential to help the vast majority of the economy succeed by offering a better approach—one that takes state-of-the-art technology and makes it more approachable, accessible and adaptable.”

    Again, we see a version of AI democracy at play. This is an exciting shift for many companies and teams that exist outside the elite tier. As an example, Grieve said that instead of “procedural code or minimalistic point solutions,” modern applications platforms “harness the power of advanced technologies and AI to create efficiencies for companies outside of the tech bubble.”

    This could be one way to level the playing field and allow companies of all sizes to complete the work needed, shrink backlogs, overcome developer drought with tools that are friendlier to citizen developers, support team collaboration, accelerate efficiency, and—for the underdogs—compete with the big dogs.

    Looking to the Horizon

    So, what does Grieve see for the future of application development? To him, it is bright if we continue on the current trajectory. “More and more,” he said, “successful development projects will require business and IT to work together and collaborate closely.”

    This means investing in sophisticated technologies, with powerful built-in AI, that can help companies ensure that even though applications are built quickly and efficiently, they are built securely and reliably—and in ways that can be easily scaled and evolved.

    If this is all to be realized, Grieve forecasts that we can look forward to “a bright future that is welcoming of a much more diverse and representative community of people who build applications together to solve all the most pressing problems.” It’s an optimistic view, but one that many will welcome as a fresh breath of air in what have been some particularly trying times.

  • DevSecOps Implementation: Source Composition Analysis

    DevSecOps Implementation: Source Composition Analysis

    This is the second installment in this series on DevSecOps. Read the first installment, on Static Analysis, here.

    One of the better additions to security in recent years is source composition analysis (SCA). The purpose of SCA is to sit in the gap between static analysis and dynamic analysis to help you find issues introduced by included libraries, projects, etc. While effective, source composition analysis is only available on open source libraries and packages, which are the highest growth areas of external sources in any project. If we are purchasing a product to include in our application, we take our time and compare and contrast to make certain we have the right thing. If there is an open source option, we just drop it in. Particularly if the option is popular—little thought goes into using MySQL database in Python or its equivalent in other languages. If a Python project uses MySQL or MariaDB, it is needed, so it is grabbed and used.

    The growth of source composition analysis is a great boon to security. Having a tool that takes care of monitoring vulnerabilities in code that is included across the board, sometimes in very uncontrolled ways, means vulnerabilities are known before the app goes live or the new release is published. Security staff doesn’t have to try to ferret out what is included in projects across the org and then cross-reference those findings with the National Vulnerability Database (NVD) or project-specific lists. The tool takes a load off security’s shoulders and makes certain developers know the risks their open source software (OSS) usage represents. The best tools notify developers when including vulnerable open source and can be configured to require approval before a vulnerable OSS library/module can be included.

    With all of that said, let’s talk about what to look for. There are some similarities with our static analysis list, but some distinct differences also. Disclaimer: As mentioned in the Static Analysis blog, this is very high-level. The research we’ve done at Accelerated Strategies Group went much deeper than we can present in a series of blogs; this is just to help you understand the top-level issues and get started down the road to a solid DevSecOps plan:

    • Language Support: This goes beyond most users’ needs in static analysis. One of open source’s strengths is building off other projects. It is often the case that Python will call C modules and some Python projects even include Go libraries. This means your chosen development tools aren’t so much relevant for scanning as the development tools chosen by projects—and their included projects.
    • Depth of Checking: Which brings us to, “How deep does the tool go?” Nesting of open source libraries can be deep and complex, with the project an application uses directly just the tip of the ice-berg. Ideally, look for a tool that answers the, “Is this even ever called?” question. It’s a good start to alert on included OSS projects and it is far better to alert on ones where the vulnerable parts are called from somewhere in the hierarchy.
    • Where to Run: The market is slowly moving to support both cloud-based and local scans. Make certain your organization’s needs are met by the vendor’s offerings.
    • When to run: Some vendors bundle source composition analysis in with their static analysis IDE plugins; others have developers run the scan command line; others offer source composition analysis at the build step—when the app is together in one place; still others offer all of the above. Again, make certain the needs of your organization are met.
    • What Is Detected: As with most security tools, this is normally a base comprised of public sources (NVD, OWASP), with add-on detection from other sources. Know what those other sources are and what they offer: that is one major difference between most products.
    • Reporting: Make certain that vulnerability reporting has everything you need. Consider the possibility that it alerts on a vulnerable OSS library in source file insecure.go. All other uses of that vulnerability need to be visible in some way from that report. Removing the reference from insecure.go is useless if reallyinsecure.go also includes it and has an exception from management to keep the inclusion.
    • Reporting Integration: While scanning OSS usage and vulnerabilities the usage introduces is important, so also is the ability to see these results side by side with static, dynamic and even interactive scans so the overall security posture of the application can be evaluated.
    • Frequency Versus Cost: OSS vulnerabilities come in unpredictable patterns, with several dropped in a week after no important ones were seen the week before. You are going to want to run these scans frequently enough to feel comfortable with your security posture, but depending upon licensing, each run might cost your company money. Make sure you understand your needs and costs associated with meeting them.
    • Licensing: The newest feature to be added to these tools is the ability to list all licenses of all included libraries so that someone can review and see what risk is introduced to the organization from licensing. Many open source projects are licensed so that commercial use is limited; this tool puts all the various licenses together so an organization can evaluate litigation risk based upon license usage. The best tools allow you to also enter proprietary license information so that all licensing relevant to an application is reviewed together.

    These tools help improve security posture by automating what is an increasingly complex manual process and bringing in vulnerability sources that security (be they secure developers or dedicated security staff) would have to manually look for. They enable shifting OSS vulnerability resolution left, allowing your team to become more agile and proactive. Make certain the tool chosen is the right one for the organization.

    As I said in the last installment, you all are keeping the lights on in a truly difficult time, making a tough job look easy. Don’t let vulnerabilities that can be caught easily with these tools but might stay hidden without stop your great work. They are relatively easy to install and configure; once you have them, you have on-demand OSS vulnerability scanning and if you are like most organizations, OSS is a huge piece of your software infrastructure. Keep rocking it, and make sure you are covered for OSS vulnerabilities and licensing.

  • How Low Code Is Transforming Software Development

    How Low Code Is Transforming Software Development

    Low code/no code is a business catalyst enabling technologies to automate processes and allowing developers to create real-time solutions for their business. With low code, businesses are able to build, customize and deploy apps with little to no coding.

    In this interview, Rackspace CTO Jeff DeVerter explains how low code is transforming software development and how Robotic Process Automation (RPA) complements low-code application platforms.

    Jeff is one of our distinguished speakers presenting at Low Code Today Virtual Summit. During his keynote presentation, he will explain the newfound prominence of low code and outline how enterprises can best utilize the technology to accelerate the delivery of software and applications.

    Find out why low code doesn’t mean “lone-coder” and why it’s important to have capabilities increased for the citizen developer by attending Jeff’ session at Low Code Today Virtual Summit on Nov. 19. To check out the full agenda or to register for free, visit the Low Code Today website.

  • Accelerate Digital Transformation With Low Code

    Accelerate Digital Transformation With Low Code

    This year many organizations have gone through a lot of changes due to the COVID-19 pandemic. Businesses need to be more agile, adapt to the new normal and accelerate their digital transformation. We have a new future of work we need to be ready for, and that requires more automation than ever before. Low code enables organizations to accelerate their innovation, automation and transformation efforts. Low-code platforms enable developers and non-technical teams to quickly deliver applications by automating the creation of apps with a drag-and-drop interface.

    In this interview, ServiceNow CIO Chris Bedi shares the main benefits of low code and talks about the ServiceNow Citizen Developer Program.

    Chris is one of our distinguished keynote speakers presenting at Low Code Today Virtual Summit. During his keynote presentation, Chris will share a CIO perspective on rolling out low-code applications at scale, best practices from rolling out ServiceNow Citizen Developer Program and suggested guardrails to ensure a successful and secure implementation.

    To find out more about the future of work with low code and how it can benefit your business, attend Chris’ session at Low Code Today Virtual Summit on Nov. 19. To check out the full agenda or to register for free, visit the Low Code Today website.

  • DevSecOps Implementation: Static Analysis

    DevSecOps Implementation: Static Analysis

    One of the things I’ve done for Accelerated Strategies Group recently is looking into DevSecOps toolsets. This is a fun area for me, as development and security fit together well in my mind. Having a separate security group is useful, even necessary in some scenarios, but letting developers crank out code and looking for vulnerabilities only after has always seemed terribly inefficient. Whenever I’ve managed developers, security training is just part of the package I bring. It’s far easier to write it well the first time (the equivalent of shift-left) than rewrite it.

    I won’t name names here—this is work I did for ASG, it is not mine to give away—but I will talk about DevSecOps today, and moving into the future. I’m planning three to four installments for this series, discussing the different aspects of DevSecOps tools.

    For clarity, we’re defining DevSecOps tools as “developer-enabled security tools.” This means that in some way, they help developers improve overall security posture while leaving them to be developers. We all know security has to shift left in every way if it’s to be useful in a DevOps world, but most organizations haven’t seriously started the move to shift security. Hopefully, this series helps.

    Depending upon which financial analyst firm you prefer, projections are that the DevSecOps market will grow 28% to 33% a year for the next few years. While this is good news for DevSecOps vendors, it implies very few organizations have systemically adopted DevSecOps, or there would not be room for that level of growth.

    Whether a traditional team or a DevOps team, the static analysis portion of DevSecOps is (generally) easy to set up and configure and most products offer feedback at both coding time and build time. IDE plugins have come a long way, some even offering advice as-you-code and others allowing developers to run on-demand static scans of their work. The industry as a whole has worked hard to lower the false-positive rates that made most organizations reluctant to deploy them broadly, and prioritization of issues is possible in the best products, making identification and remediation pretty easy. Try a pilot out: Pick a vendor and project, grab the IDE plug-in and check out what they can do. Most do not yet directly support code smells, but I suspect that is coming rapidly, as the systems are already designed to look at source and determine issues. Adding to the collection of possible issues will be a differentiator that quickly turns into a market requirement.

    Things to check for:

    • Language support: Do the languages you use have a scanner? While most of the tools on the market offer support for a breadth of languages, there are differences, so check the corner cases. This truly is a make or break decision—the best product on the market is useless to your org if it doesn’t support the languages you use.
    • IDE integration: This is pretty straightforward, are the IDEs your developers use day in and day out supported? Most of these tools offer command-line variants also, so it is possible that even without support directly in the IDE, the security functionality of a given product dictates that command-line is better. In that scenario, a process to ensure developers are even running scans is a good idea.
    • Vulnerabilities detected: At a minimum, support for whatever is currently in the National Vulnerability Database (NVD) should be required, along with OWASP compliance. Most vendors offer support beyond the NVD, so a bit of research to see what types of vulnerabilities are detected will be in order.
    • Click-through support: With IDE plug-ins, one of the great strengths of scanning is the ability of the developer to simply click on the vulnerability in the results list and go to the offending code. Make certain this works—and works as advertised.
    • False-positive rate: This has historically been a problem, but the industry has brought it down overall. Ask your prospective vendors to share their numbers. Our experience shows low single-digits for a percent, which is far better than the past, but still leaves room for improvement.

    The other part of static analysis is plugging static analysis into the build process. Most of these products have integrations into the most popular build management tools. Scanning the entirety of the application allows the static analysis to see a broader vision of the app and note issues with interactions between portions written by different developers. Reporting for build-time scans is generally at the application/team level, and the best tools will show results of development-time scans side by side with build-time scans if you want them to.

    Things to check for:

    • Language support: Again with the languages. It’s pretty simple here: The core of the application may be built using languages a given vendor supports but critical parts might not. Integration is where that becomes a real issue. Make sure what needs scanning can get scanned.
    • Integrations: Most of these tools offer automated scans through integration with build tools or manual scans that the build manager can kick off. Automation is preferred by a long shot, so check if your tool of choice is integrated into your organization’s build tooling.
    • Depth: We’re not going to get into source composition analysis (SCA) here—that’s for another blog—but we are going to observe that vulnerabilities can come from your source’s sources. How far does the scanning tool trace in a static analysis situation? Is it deep enough to cover a given application’s integrations and inter-relationships? While SCA will detect a lot that static scanning won’t, things such as “unsafe values sent to [insert external API]” should be available in static code analysis.
    • Reporting: This is where you’ll find the most variety in popular tools. Look at their reporting and click-through support to find what best suits your needs.
    • False-positive rate: Same as IDE integrations above—make certain it is low enough for your organization’s comfort.
    • Scan run location: This is becoming a differentiator in the space—do you want your scans run in the cloud? In the data center? Some mix of both? Check your vendors; there are significant differences in the level of support for these options.

    This is just the tip of the iceberg, of course. It is an entire market segment, and static analysis tools have been around a long time. Many organizations have not taken dev-time security seriously yet, even though we all know we need to; I’m just offering a place to get started.

    DevSecOps just makes sense. Static scanning is mature and generally well-integrated. This is a great place to start shifting security left. We get it: Developers don’t want to be security analysts or they’d have filled one of those many security openings. But IDE integration makes these scanning tools more interactive and less intrusive, showing developers how to do it securely as they code. This is great to me because good coding practices will become second nature with real-time, on-the-spot reminders and pointers. It also means that if the developer acts upon the tool’s recommendations, the code is developed more securely the first time and there will be no need to revisit it for security proofing.

    You’re all keeping the lights on in a terribly tough time. DevSecOps attempts to make it more likely that your astounding work isn’t interrupted. It just makes sense to get these tools to protect your organization’s portfolio and your hard work.