devopsy.kinsta.cloud

Tag: software development life cycle

  • Navigating the Maze of SSDLC Models: A DevOps-Centric Analysis

    Navigating the Maze of SSDLC Models: A DevOps-Centric Analysis

    In the rapidly evolving world of software development, the integration of security into the software development life cycle (SDLC) is no longer a luxury but a necessity. The concept of secure SDLC (SSDLC) has become pivotal in ensuring the creation of software that is not only functional and efficient but also secure from the ground up. With a plethora of SSDLC models available, such as Microsoft’s security development lifecycle (SDL), the OpenWeb application security project’s software assurance maturity model (OWASP SAMM), and others, it’s crucial for organizations, especially those embracing DevOps, to understand their distinct characteristics. This article provides an insightful comparison of these models, highlighting their strengths, weaknesses and applicability to various project types, underpinned by relevant statistics and research findings.

    Microsoft’s Security Development Lifecycle (SDL)

    Microsoft’s SDL, introduced in the early 2000s, is a security assurance process designed to reduce software vulnerabilities and address compliance requirements. A notable aspect of SDL is its emphasis on security training for developers, a practice that has been shown to reduce the introduction of security flaws by up to 30%. The SDL framework includes security-focused activities such as threat modeling, code reviews and security testing throughout the SDLC.

    Strengths: SDL’s structured approach is well-suited for large-scale, complex software projects. Its comprehensive documentation and detailed guidelines are beneficial for organizations seeking a thorough security framework.

    Weaknesses: The extensive nature of SDL can make it cumbersome for smaller projects or teams that adopt rapid development cycles typical in DevOps environments. Its prescriptive nature may also stifle agility.

    OWASP’s Software Assurance Maturity Model (SAMM)

    OWASP SAMM offers a flexible and prescriptive approach to integrating security into software development, making it particularly attractive for organizations adopting DevOps methodologies. SAMM focuses on continuous improvement and can be tailored to an organization’s specific needs.

    Strengths: SAMM’s flexibility allows it to be easily integrated into various development processes, including Agile and DevOps. It supports incremental implementation, a critical factor given that 60% of companies are adopting some form of DevOps practices.

    Weaknesses: Its less prescriptive nature can be a double-edged sword, potentially leading to inconsistencies in implementation. Organizations without a strong security background may find it challenging to interpret SAMM’s guidelines effectively.

    Comparing SDL and SAMM in a DevOps Context

    When viewed through a DevOps lens, SDL and SAMM cater to different organizational needs. SDL’s structured approach is ideal for large enterprises with well-established development and security processes. However, its rigidity may clash with the dynamic, iterative nature of DevOps. In contrast, SAMM, with its adaptability and emphasis on continuous improvement, aligns more closely with the principles of DevOps. It allows for faster integration and adaptation in a fast-paced development environment.

    Other Notable SSDLC Models

    Beyond SDL and SAMM, other models like the V-Model, Agile SDL and BSIMM (building security in maturity model) also offer unique perspectives. For instance, the V-Model’s linear and straightforward approach is well-suited for projects where requirements are well-defined and unlikely to change, a scenario less common in DevOps-focused organizations. Agile SDL integrates security practices within Agile methodologies, making it a viable option for teams that balance rapid development with security considerations. BSIMM, based on real-world data from over 100 organizations, provides a benchmark for companies to measure their secure SDLC practices against industry standards.

    Tailoring SSDLC to Project Needs

    A one-size-fits-all approach does not work in the realm of SSDLC. The choice of model depends largely on the organization’s size, the nature of the project, compliance requirements and the existing development methodology. For instance, one survey indicated that 45% of small to medium-sized enterprises prefer flexible models like SAMM due to their limited resources and need for agility.

    The Role of Automation and Tooling in SSDLC

    Irrespective of the chosen model, the integration of automation and tooling plays a pivotal role in the successful implementation of SSDLC in a DevOps environment. Automated security testing tools, for example, can identify vulnerabilities early in the development cycle, a practice that has been shown to reduce the cost of fixing security issues significantly.

    Evolving Security Challenges in the DevOps Era

    As the software development landscape continuously evolves, so do the security challenges, especially in the context of DevOps. DevOps practices, which focus on integrating development and operations to enhance agility and efficiency, also bring unique security considerations. The rise of microservices architectures and containerization, for instance, has introduced complexities in managing security at scale. Data suggests up to 70% of organizations using microservices have faced security incidents due to misconfigurations.

    In this context, SSDLC models must evolve to address these new challenges. For example, incorporating security into container orchestration tools and ensuring secure service mesh configurations are becoming increasingly important. Furthermore, the integration of security into continuous integration/continuous deployment (CI/CD) pipelines, a hallmark of DevOps, demands that SSDLC models be adaptable enough to automate security checks without impeding the speed of deployment.

    Bridging the Gap Between Security and Development

    A critical aspect of SSDLC in a DevOps environment is bridging the gap between security and development teams. Traditionally, these teams have operated in silos, often leading to security being considered late in the development process. This misalignment can be costly. Research has reported that identifying and fixing security vulnerabilities post-deployment can be 100 times more expensive than addressing them during the design phase.

    To mitigate this, modern SSDLC models are increasingly advocating for a ‘shift-left’ approach, where security considerations are introduced earlier in the development process. This approach not only reduces the cost and effort associated with addressing security issues but also fosters a culture where security and development goals are aligned. Tools like automated security scanning and threat modeling are instrumental in this regard, enabling developers to identify and rectify security flaws early.

    The integration of SSDLC into DevOps is not just about selecting the right model but also about adapting to the evolving landscape of software development and cybersecurity. By understanding and addressing the unique challenges posed by DevOps practices, organizations can create a more secure and efficient development environment. Whether adopting Microsoft’s SDL for its structured approach or OWASP’s SAMM for its flexibility, the key lies in tailoring the SSDLC model to fit the organization’s specific needs, culture and project requirements. As we move forward, the convergence of security and development will continue to be a cornerstone in the journey towards creating resilient, secure software.

    Conclusion

    The landscape of SSDLC models is diverse, each with its strengths and weaknesses. For organizations embracing DevOps, the choice of SSDLC model must align with their culture of rapid development and continuous delivery. Microsoft’s SDL offers a robust and structured approach, ideal for complex, large-scale projects. OWASP’s SAMM, on the other hand, provides the flexibility and adaptability needed in a fast-paced DevOps environment. Ultimately, the decision should be guided by the organization’s specific needs, project characteristics and security objectives, ensuring that security is ingrained in the software from inception to deployment and beyond

  • Zenhub Brings Issues Management to Project Management Platform

    Zenhub Brings Issues Management to Project Management Platform

    Zenhub today announced it is adding an issue management module that makes it simpler for stakeholders to collaborate with developers on application development projects without having to log into a GitHub repository.

    Fresh from raising an additional $10 million in capital, Zenhub co-founder Aaron Upright said Zenhub Issues is a plug-in for a project management application the company developed for GitHub environments to better streamline software development life cycles. The issue is that many application stakeholders, such as marketers, are not especially pre-disposed to logging into a repository for managing software components, he said.

    Zenhub Issues provides an alternative means for collaborating with developers that doesn’t require stakeholders to log into GitHub, he said. In addition, organizations no longer need to acquire additional GitHub licenses for those users, noted Upright. Many of those end users wind up with read-and-write access to software components, which creates unnecessary cybersecurity risks should their credentials be compromised, he noted.

    In some cases, organizations will also be able to eliminate the need for the project management applications many of those stakeholders have adopted because they can track issues via Zenhub Issues, he added.

    Many organizations’ entire business strategies now revolve around accelerating the rate at which software development projects can be completed. Many elements of those projects, however, can’t go forward until a specific component upon which it depends is completed, so project management has become a critical function. Investors are holding business leaders more accountable for software delivery timetables that have direct implications on revenue generation, so that pressure naturally falls on DevOps teams.

    It’s not surprising that there aren’t a wider range of end users of project management applications as various stakeholders seek to keep closer tabs on how updates to schedule impact their planning cycle. Everyone from the sales team to the board of directors now wants more visibility into the rate at which software development projects are being completed. The challenge DevOps teams face is that software development is an inexact science. Application development projects can just as easily fall behind schedule as they can leap ahead depending on how well code is written.

    Regardless of how application development projects are managed, the relationship between DevOps teams and the rest of the organization has fundamentally changed. Unfortunately, expectations are not always realistically aligned with available development resources. A project management application that is widely employed across an organization should make that apparent to all interested stakeholders. In theory, at least, that should result in either the hiring of additional developers or a reassessment of the business strategy.

    One way or another, project management applications designed for managing software development projects now play a pivotal role in business planning. The challenge is finding a way to populate those applications with the data needed without requiring developers to help enter data that can already be easily pulled from the DevOps tools and platforms. Otherwise, instead of being viewed as a benefit, the entire project management process becomes one more tedious task that development teams are not going to prioritize over writing code.

  • Why Your Business Needs DevOps

    Why Your Business Needs DevOps

    One of the biggest headaches IT leaders face today is managing cross-functional teams to develop and deploy high-quality software faster. Not only does their work have to be continuous to stay productive, but there’s the need to save the business money, time and improve end user and customer satisfaction while fixing a seemingly endless parade of bugs.

    Without a robust DevOps process in place that benefits the entire organization, IT management and tech leaders often feel like they are chasing the impossible.   

    What is DevOps?

    DevOps is a set of practices that help you plan how both development (Dev) and operations (Ops) teams can work cohesively to deliver your company’s products and services, meet customer needs and stay ahead of your competitors. In short, it is a set of tools that leverages people, processes and technology to enable safer, faster handling of any IT software delivery initiative.  

    Yet, according to Gartner, as of the beginning of 2022, 75% of DevOps initiatives have not met these expectations because of inefficient collaboration, lack of buy-in from employees, trying to do too much too quickly and unrealistic expectations. For a methodology that is so critical to businesses today, it’s still surrounded by uncertainty and doubt. Let’s look at how you can make DevOps work for you and why it’s so important that you do so.

    Addressing Bugs

    Because detecting and addressing software bugs is a major priority of any IT department, disruptions need to be handled quickly and efficiently. This can only be done through immediate action and a tried-and-testing workflow in which all departments involved can act fast. The beauty of DevOps is that the process can be continuous rather than reactive and thus improve the quality of your software when deploying new features, as DevOps allows you to make changes rapidly. 

    Without DevOps, productivity is slowed or even brought to a halt which leads to an often-damaging customer experience.  

     Improving Customer Satisfaction

    A significant benefit of adopting DevOps practices is that it lowers the failure rate of new features while improving recovery time. The continuous deployment, testing and feedback loops ensure faster service delivery and happier customers. The development team can focus on creating superior products by automating the software pipeline while the operations team can improve business delivery. 

    Faster delivery of your products and services should not be a pipe dream. Those who understand and implement DevOps should feel confident they can stay ahead of the competition. 

    Improving the Security of Your Software

    DevSecOps builds on the DevOps pipeline to integrate security from the very beginning of the development cycle rather than at the deployment stage when flaws and vulnerabilities are more difficult and costlier to fix. Combining development, security and operations across your products and services will improve quality, security and your ability to meet client expectations. Building security into your pipeline seamlessly means bugs and other issues can be addressed more easily and remain almost unnoticed to the end users.

    DevOps and DevSecOps make this possible so that outdated security practices are not integrated into your software and don’t interfere with customer demand. So, if increasing customer satisfaction and positively impacting your bottom line by delivering high-quality, secure and effective software is on your business priority list, then implementing a DevOps process can not only save IT headaches but deliver better business outcomes.

  • Secure Software Summit: Measuring and Mitigating OSS Risks

    Secure Software Summit: Measuring and Mitigating OSS Risks

    Measuring and mitigating the security risks in open source software is becoming a major issue in the software development community. Attacks on open source software (OSS) are on the rise; open source supply chain attacks grew 650% in 2021—a staggering number.

    2021 and early 2022 saw significant attacks which impacted more than 1,000 organizations. The most prominent recent OSS attack was the Log4Shell vulnerability disclosed in December 2021. Attacks on the OSS supply chain and on OSS impacted nearly every single software organization on the planet. Everybody is scrambling to continuously patch systems as new vulnerabilities continue pouring in.

    To properly navigate this environment and keep our systems safe, we as a community need to understand the security risks of OSS and be better prepared to handle them, collectively and individually. 

    Open Source Risks

    There are a number of risks that make OSS more vulnerable without proper security measures. 

    OSS is Free; OSS Security is Expensive

    To start, we must recognize that open source software may be free to download and require no payment, but it comes with a massive security cost. 

    A significant portion of open source software is developed by volunteers in their free time. Most of the prominent open source volunteers actually have full-time jobs, and the code they contribute to projects like the Log4j logging libraries are written on nights and weekends; on their own time and not on the company dime. Not surprisingly, security isn’t high on their priority list. They don’t have the resources to invest in a secure development life cycle or have the time and bandwidth to maintain their code. This may mean that security vulnerabilities remain unaddressed for long periods of time, sometimes indefinitely. 

    All Bugs are Shallow, but There Aren’t Enough Eyeballs

    In software development, Linus’s law states “…given enough eyeballs, all bugs are shallow.” However, this is only true if those eyes are looking in the right place. In the case of open source, all code is open but there aren’t enough eyes paying attention to it to spot all the bugs. In addition, organizations may not consider the security consequences of their decision to consume a particular piece of open source software and adding it as a dependency. Dependency trees become more and more complex; harder and harder to monitor and secure, as you keep adding more third-party components to a core codebase. Each new dependency might bring additional nested dependencies—perhaps hundreds or thousands, depending on the size of the library added or the role it plays in the application architecture. For example, the Kubernetes project—one of the most successful and widely adopted OSS projects—has several thousand dependencies, many of which have additional secondary and tertiary downstream dependencies. 

    So Much Code. So Many Choices. Not all are Good.

    The beauty of the open source ecosystem is that there is a solution for everything. The problem with the open source ecosystem is that there’s not just one solution, but several dozen. For example, if you need a JSON parser for your application, there are several to choose from. If your application is running a critical service or infrastructure, then picking the right JSON parser—one that is secure and comes from a responsible project or maintainer—becomes very important. A JSON parser will serve as a critical component for your application, so it will impact the security of your entire system. If you chose the wrong JSON parser, you might pay a big price down the road in security risk and subsequent breaches. 

    Proposal: An Entry Gate Security Risk Assessment

    One potential solution to enhance OSS code security is the creation and implementation of a security risk assessment gate as part of your OSS ingestion pipeline. Putting this process in place will help you understand whether consuming a certain piece of software is high risk and avoid software that does not meet your risk criteria. 

    Here is an example of how this might work. Consider five different JSON parser libraries in GitHub, all of which have a high number of stars and appear to be highly rated. How can we assess the risk of these libraries and quickly and easily eliminate ones that are too risky? One of these JSON libraries is hosted under a user account. Most of the commits are done by a single developer without reviews. This alone indicates that using this library in a critical system presents a high risk. This lone developer could commit malicious code without review. The maintainer’s token access could be leaked, allowing attackers to insert malicious code. The developer might also turn over committer control of their library to a malicious actor without notifying users (who might not pay attention to the notification anyway). Identifying this risk required no more than a few minutes of review of the repository and cost little in time or effort. 

    A Broader View of Security Posture for OSS

    More broadly, we need to understand the full security posture of an organization or developer and their open source code prior to adding it to critical systems. Because OSS is a complex ecosystem and many pieces of OSS are complex, the risks they generate are similarly complex. Our traditional, myopic view of these risks is that we just need to find all the security vulnerabilities in our codebase and fix them. This does not resolve all risks and may lull us into a false sense of security.

    We need to understand the full comprehensive security posture of an open source project. That involves understanding a broad range of risks beyond code vulnerabilities. Here are some of the key risks to consider beyond ensuring that your codebase is well-secured and patched. 

    Supply Chain Attacks on the Build Pipeline

    Attacks like SolarWinds and CodeCove taught us that supply chain risk is a very big deal and that tools are just as much at risk as code. Attackers have found it much easier and much more reliable to attack build pipelines, rather than finding vulnerabilities in code.

    Security Risks Revealed by Continuous Security Testing 

    Continuous security testing is critical to maintaining the security of a codebase. There might not be code vulnerabilities today, but as developers continuously modify code and iterate on applications, vulnerabilities may be introduced. This can mean testing code as part of the CI/CD process with every new code push. For example, we have found numerous critical bugs in OpenSSL libraries. All were caught on a master or main branch and never made it to a production release. 

    Project Maintenance and Capabilities

    One of the really big risks with open source is the quality and frequency of project maintenance. Issues raised may not be addressed in a timely fashion. Maintainers of a project may have a long backlog of issues, indicating that they are not actively maintaining a project. It is not uncommon for critical open source projects used in millions of applications and comprising a significant dependency to the global software supply chain to not have been updated in a year or more. In addition, maintainers of OSS projects may not know how to respond to security incidents and fix security vulnerabilities. This is particularly true if the maintainers do not work at a large organization, do not have cybersecurity or secure development experience or have never suffered through the toil and trauma of addressing a major vulnerability in their code on short notice. 

    Tools for Measuring and Addressing Supply Chain Risk

    A number of efforts are underway to create free tools to help developers and application security teams better measure and address supply chain risk programmatically and analytically. 

    SLSA—Supply Chain Level for Software Artifacts

    As a tool to help organizations better address software supply chain risks, Google created a novel framework that we call Supply Chain Level for Software Artifacts (SLSA). The project has been underway at Google for more than a decade and has been open sourced as part of the OSSF. Contributors include VMware, Citibank and Datadog, among others. Google hopes to standardize SLSA and make it an industry benchmark for evaluating supply chain risk. Right now, SLSA is focused primarily on build process risks but the hope is to expand it in the near future to other areas, such as vulnerability and maintainer risks.

    OSS Security Scorecards Project

    In order to scale the process of assessing, identifying and mitigating risks in OSS, we need robust automation. In 2020, as part of the OSSF, Google released a new project called Open Source Security Scorecard. The project aimed to automate the analysis and trust aspect when evaluating the security posture of open source code. Further, the Scorecards can provide specific security recommendations. The Scorecard process can incorporate many other automated tools, including checking against vulnerabilities using the Open Source Vulnerability (OSV) database and running dependency checks using open source dependency trackers like Dependabot. The scorecards project also makes it easier to report new vulnerabilities and get those to the right people in a project. 

    Conclusion: What is not Measured is not Mitigated

    No one denies that OSS has become crucial to the vast majority of applications running the world’s technology foundation. The span of OSS continues to grow, as more and more languages and frameworks emerge and specialization increases. No one wants to reinvent the wheel and rewrite fresh code to perform the same tasks with every new application. The model of reuse, dependency and distributed software development works and speeds innovation. That said, the open source community and the supply chain used to build OSS need a more rigorous approach to reducing risk. Given the scope of the problem, automation and standardization are helping to scale toward the stated goal. We are in the early stages of creating the tools and infrastructure to automate the risk identification, measurement, assessment and mitigation processes. Security frameworks like SLSA and new processes like entry gating new OSS code with security scorecards will direct organizations down that path and move us toward a more secure open source future.

    About Secure Software Summit
    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay

     

  • Stop Hiding the Cloud From Your Developers

    Stop Hiding the Cloud From Your Developers

    If you say a person or organization “goes to great lengths” to achieve something, it means they try very hard and perhaps do extreme things to accomplish their goal. One example I’ve seen is that of more traditional companies “going to great lengths” to “hide” the cloud from their pool of potential technical consumers doing work like development. Instead of saying, “Here it is,” they block or restrict users from direct consumption. Under this model, developers don’t directly login to Azure or AWS, they go to the “internal corporate portal” and fill out a request form for the resources they want and submit it. Then, someone eventually processes the request and creates what is needed.

    In extreme cases, organizations create “cloud teams” and staff those groups with people who build cloud resources on behalf of downstream technical consumers, like developers. Potential consumers must submit a request with a detailed design document specifying everything they want. Then, the cloud team schedules the project and delivers it at a future point. The whole process mimics the historical waterfall approach to software development or systems implementation.

    Why do things this way? It always seems to come down to four distinct drivers:

    Costs: “If we give open access, we will end up with a huge bill!”
    Compliance: “Everything built must meet our security standards.”
    Complexity: “Most users will waste time trying to figure it out.”
    Control: “Our group has always coordinated access to resources.”

    In traditional companies, the reasons for this restricted access always seem to be some variation of those on the list. And when you rebut with something like “Do you think Facebook, Twilio, Netflix, etc. restrict their developers’ cloud access?” the answer is usually something like, “Well, those are elite tech companies; we’ve always done it the way we do it now …”

    In most cases, there is no singular argument you can make to change someone’s mind, or expand the range of possibilities. But you can offer facts. So, let’s take on their arguments one at a time and see if we can rebut them.

    Costs

    Argument: “If we open up the cloud to everyone, then all the developers will endlessly create virtual machines (VMs) and associated resources and services, and we will end up with a huge bill.”

    Rebuttal: There are certainly examples of this; do a search for some variation of “unexpected cloud costs,” and they’ll pop up, especially from a few years ago when cloud adoption was just taking off. But what about today? What can be done to control costs? Even though there are lots of tips and ideas on how to control cloud costs, I’ll offer one simple possibility that directly applies to developers and development groups that is not often mentioned in many articles: implement a cloud resource quota per developer or dev group.

    In AWS, for example, you can allocate via IAM; with Azure, you can use resource groups. The upshot is that there is a way to restrict the number and amount of resources that a single user can consume. So, whether you have 10 or 1,000 developers, you can use these built-in mechanisms to limit and then estimate what your consumption will be. If I have 100 developers and I put a limit on the number of VMs, the number of GB of RAM they can allocate and the amount of storage each developer can consume, then haven’t I just created a “cap” on consumption? The quota concept gives you a path to a “predictable” bill every month.

    Compliance

    Argument: “If we open up access to everyone, they’ll create VMs that don’t adhere to all our internal security standards.”

    Rebuttal: Aren’t developers just looking for a VM (or VMs) to do dev work? We aren’t talking about building production-hardened VMs to host applications. We are talking about giving developers the proper sandbox in which to do their work. So, from this perspective, requiring that developers only create VMs that adhere to strict compliance standards reserved for production servers doesn’t make sense.

    For example, maybe one of your compliance standards is that all production servers have a monitoring agent installed on them. Fine, that makes sense; what about dev/test? In dev/test, I might be spinning up a VM or a container that only exists for a short time, maybe even less than an hour while some tests are running. Does it make sense to require that a monitoring agent be installed on a VM that will only have a one-hour shelf life? Just throwing out the term “compliance” as a catch-all is not a real solid objection. Perhaps for dev/test, there are minimum standards you would want to follow regarding OS levels, patches, etc., but the VM(s) you use in dev/test do(es)n’t necessarily need to have all the additional security requirements reserved for production servers.

    The other part of this objection we hinted at earlier is that you have to transition to “cloud thinking.” Resources that exist for the next 10 minutes in the cloud could intentionally be gone shortly after that. In the cloud, you can quickly create and destroy VMs, or entire environments of VMs. That is what makes the cloud a game-changer versus traditional on-premises methods. You can’t apply the same on-premises considerations to the cloud one-to-one. You need to come up with a new thinking model that takes into account what it means to use the cloud versus how you did it before on-premises.

    Complexity

    Argument: “It’s too hard to figure out some of these cloud architectures, and developers will waste time trying to do so versus having a central team do all the work correctly the first time.”

    Rebuttal: Without the commitment to being a “learning organization,” there can be no DevOps, no transition/migration to the cloud, no digital transformation. Check out item number six on this list of 7 Ways to Make Developers Happy. (Spoiler alert: it’s ‘promote continuous learning.’)

    If “complexity of learning” is one reason why you restrict your teams’ access to the cloud, then you are missing the point of what it means to be a technical expert. Developers partially define themselves by the depth and the range of knowledge that they have accumulated, so continuous learning is a significant component of keeping developers “happy.” Not to mention that happy developers are more engaged and tend to stick around longer at companies that keep them that way; you’re risking losing the technical talent you do have, which has a host of detriments to your organization.

    Control

    Argument: “If developers are creating their own servers, what does our team do?”

    Rebuttal: This one is the toughest of all to rebut. Many organizations have one or more infrastructure teams who are responsible for creating servers and resources and giving access to downstream consumers. These groups control the resources. Now, along comes the cloud where everything can be self-service. And the natural reaction is, “If developers are creating on their own, what do we do?”

    For many traditional companies making the transition to the cloud, there will still be many opportunities for participation. Instead of “architect,” now we need “cloud architect.” Instead of “engineer,” now we need “cloud engineer.” Also, what other higher-value work could you be doing for the company if you weren’t spending all your time provisioning and maintaining on-premises servers? Do you think all of the existing on-premises applications are going to go away overnight? Will your company become “cloud-native” in the next six months? What about all of the AIX, IBMi, Solaris and other legacy components that are in the data center? There will always be plenty of work for everyone to do. And it’s always an opportunity to learn some new skills.

    The reality is that giving developers direct access to the cloud (with controls) frees up many other corporate resources to work on things that are, strategically, more important. If your company is not cloud-native right now, then guess what? It won’t be for a long time. Maybe in the short term, you’ll be hybrid-cloud and then in the long term, cloud-native. Along the way, there will be opportunities for everyone to rethink how things get done and maybe learn something new along the way.

    If you are hiding the cloud from your internal customers, ask yourself, “Why?” Are the original reasons still relevant, or are they holdovers from a time long past? Maybe it is time to re-examine your original rationale for why developers don’t have direct access to the cloud. If the goal of your organization is to “service the customer,” “do more,” “move faster,” etc., then removing internal barriers to accessing the cloud is one way to make progress.

  • Future-Proof Your Product Development Life Cycle

    Future-Proof Your Product Development Life Cycle

    In product development, change is vital. In fact, some might say that product development is the embodiment of change. Continuous improvement keeps products from becoming stagnant, which, in turn, keeps companies afloat.

    While change is important, it’s not always helpful, especially when it involves the management of employee attrition and retention. Over the last year, many organizations have witnessed how an uncertain business environment can leave their workforce in chaos. Every year, thousands of experienced developers and engineers in the product development ecosystem leave their jobs, taking valuable tactics, insights and tools with them to their next role. Though these workers often pass on their expertise to those who take their place, without formal systems or standardized processes for gathering that information, much of the knowledge will be lost. The ultimate result is an increase in development costs and deployment delays.

    We’ve all heard the phrase, “You don’t know what you’ve got until it’s gone.” When it comes to an employee, that individual’s informal knowledge isn’t always easily captured by existing internal company processes. To retain and protect this knowledge, companies need technology that makes it easy to gather, store and access for future use.

    Enter future-proofing, the process of using digital tools to capture knowledge and make accessibility seamless for future employees at various stages of product development. Employing future-proofing strategies will help IT company leaders and decision makers ensure a continuum throughout the product development life cycle.

    Future-proofing is especially vital in this age of digital transformation, as it helps address common concerns that crop up about collaborative environments, team efficiencies and product integrations. Let’s take a look at what this entails.

    Future-Proofing in the Age of Digital Transformation

    The best-case scenario for adept future-proofing in the age of digital transformation is to have product development adapt alongside any systemic changes. Under these terms, software solutions that holistically capture both formal and informal knowledge are the secret to future-proofing the product development process. An effective digital solution will help you do this in three ways:

    • Comprehensively enables collaboration: A comprehensive solution will give users a single source of truth to track decisions, questions and problems. Unlike a shared Excel spreadsheet or Word document that can get overwritten, forgotten, corrupted or contains incomplete, fragmented information, future-proofing tools can effectively gather, store and then pass along knowledge.
    • Increases team efficiency: By working from a single source, teams can capture knowledge – often without even realizing it – through feedback and team communication. Additionally, a single source of information reduces design inconsistencies and discrepancies.
    • Seamlessly integrates digital tools: Because product development does not rely on a single digital system, solutions need to be integrated across different digital tools and throughout the product development life cycle. By integrating with tools that track development and with other information gathering and tracking solutions, knowledge is captured at multiple levels, streamlining future projects.

    Overall, fostering an environment that encourages teamwork is the best way to ensure knowledge sharing and preservation. However, when that is not possible, companies need to have a backup plan. By merging talent with technology, you can capture both formal and informal knowledge before an employee walks away, and, therefore, future-proofing your product development life cycle.

  • AI Automation Won’t Replace Jobs – It Will Replace Processes

    AI Automation Won’t Replace Jobs – It Will Replace Processes

    As Software 2.0 takes shape, how are AI processes—and the jobs that go with them—changing?

    When it comes to new AI automation, the Software 2.0 movement can be seen as akin to the auto industry’s recent evolution. Beginning in the 1990s and rapidly progressing into the 2000s, the auto industry saw a huge rise in AI automation such as digital vehicle diagnostics.

    Throughout this, people worried that digital transformation might take jobs away, when instead it led to “greater profits, productivity, and competitiveness,” according to a 2008 study by the journal of Technological Forecasting and Social Change. In short, these innovations didn’t replace jobs, per se; they simply changed the processes of jobs from the manufacturer’s assembly line down to the mechanic’s garage.

    An auto diagnostic specialist used to perform tedious tasks such as counting flashes and converting them to error codes on printed-out tables. Computerized diagnostic tools made this process faster, more reliable and, you might imagine, far less tedious. According to diagnostic specialists Helmut Frank and Uwe Schmidts, digital transformation went from being “a necessary evil to being a key to new, interesting and innovative functions.”

    You might liken the above example to the innovations that AI automation and machine learning (ML) have offered to software developers, who until recently, were tasked with a much more hands-on approach to deploying and maintaining applications. In many ways, DevOps practices have heroically come in to break them free of this minutiae, automating many of the repetitive tasks involved in application management. By design, it’s increasing efficiency and security while decreasing tedium and the chance for human error.

    Speaking to tedium, Mike Loukides and Ben Lorica, in their article “The road to Software 2.0” noted, “Up until now, we’ve built systems by carefully and painstakingly telling systems exactly what to do, instruction by instruction. The process is slow, tedious, and error-prone; most of us have spent days staring at a program that should work, but doesn’t.”

    In short: Much like digital transformation brought efficiency to the life cycle of automobiles, AI automation is offering efficiency to every stage of the software development cycle.

    Don’t Change the Players, Change the Game

    Indeed, a new generation of AI automation and ML tools is now emerging, shaping what some call a Software 2.0 movement. But before you begin to fear that these tools will lead to a “they took our jobs!” revolt, consider that they may be celebrated instead as a means of not only augmenting the work of software developers but also helping offset the ongoing developer drought. According to a 2019 Stack Overflow survey, over a third of developers named “not enough people for the workload” as their primary challenge to productivity. Rather than replacing jobs, automation should be viewed as offering efficiency in an industry that desperately needs it.

    As an example, the process of writing code, though more streamlined today than it was 25 years ago, has remained a mostly manual process. This has presented an excellent opportunity for the automated processes we are beginning to see, which bring in AI to automate aspects of code development such as program synthesis, smart code completion and static code analysis.

    Assaf Araki spoke to this in the article, “Software 2.0 takes shape.” Araki described how automation is filling gaps in many other areas, such as regression testing, code analysis, AI for vulnerability detection and observability tools to monitor software health.

    From Monolith to Microservices

    Just like the recent, mysterious disappearing monolith in the Utah desert, the relevancy of monolithic development may be on its way out.

    In the past, software cycles were longer. Teams updated monolithic-style deployments only monthly or yearly. Nowadays, companies are under pressure to push much more rapidly, often turning to microservices and progressive release strategies. This new paradigm requires much automation to increase release efficiencies and enable a seamless CI/CD.

    As Araki pointed out, “Automation in software is best viewed through the lens of Continuous Integration (CI) and Continuous Deployment (CD).”

    How to Know When AI Automation is Worth Its Salt

    It’s smart to consider the investment of both money and time when deciding whether an AI solution is worth adopting. “AI systems need to add value that exceed any new costs and requirements (such as the need for labeled data, hiring new staff, etc.),” Araki said.

    You should also be asking if the solutions are wide-ranging enough to meet the needs of your developers and anyone else on the team who may be employing them. Key considerations for AI automation, Araki noted, are focusing on tasks and systems that are frequently used, adjusted or tuned.

    4 Examples of Versatile AI Automation and ML:

    1. Data management systems from simple systems that employ ML to more complex systems that enable self-driving data management.
    2. Dashboards that are automatically created, ideally with intuitive and visually appealing UX, that use AI automation and ML to bring up the right elements—more progress is expected in these areas in the coming years.
    3. Websites and mobile apps that use AI automation to become highly personalized interfaces, such as those that employ real-time data for online and reinforcement learning—these are also expected to progress in the coming years.
    4. UX and design tools that use simple automation to design and revise digital media, with ML being a promising way to kick the automation up a notch, such as deep learning for game developers.

    AI Automation and ML to Grant Opportunities

    In short, Software 2.0 doesn’t currently appear poised to threaten jobs or decrease developer need. Instead, it seems to be changing the processes engineers are using and creating efficiencies in their work, at a time when their expertise is in increasing demand. Demand for novel roles, like the Cloud Economist, demonstrates the emergence of new opportunities for humans with cloud knowledge who work alongside AI.

    The new evolution of AI and ML also could create a unique subset of developers with skills keeping par with these new innovations—much like digital transformation in the auto industry led to evolving specialties in computerized vehicle systems.

    Not to mention that just as low-code has paved the way for citizen developers and AutoML led to citizen data scientists to fill large gaps in demand, AI and ML solutions have the potential to further broaden and democratize software and code development.

  • How to Make DevSecOps a Reality

    How to Make DevSecOps a Reality

    DevSecOps is an increasingly popular term; however, security vulnerabilities in software continue to proliferate. 2019 saw a surge in web application breaches shining a spotlight on the fact that DevSecOps remains elusive. The latest data from the Verizon Data Breach Investigations Report (DBIR) identified that web application vulnerabilities had doubled in the last year alone.

    With the rapid pivot to all things digital in 2020, the pressure on software and applications continues to intensify. Security needs to be a fundamental part of software development in our digitally dependent world. This requires organizations to focus on more than the speed of delivery and turn their attention to the quality of software as they try to accelerate the pace of digital transformation.

    Achieving DevSecOps

    Organizations striving to achieve DevSecOps need to adopt the following steps to embed security throughout the entire software development life cycle (SDLC).

    Make Security a Priority From Day One

    Security can’t be a bolt-on at the end of the SDLC if your goal is to make DevSecOps a reality. The recent Zoom failures put security flaws in the spotlight and showcased the risks resulting from delivering innovative services without factoring in security. Every member of the team spanning product developers to technical architects to scrum specialists must consider security for it to be an intrinsic part of each stage of development.

    Achieving this transformation to DevSecOps means rethinking how to determine success. Many organizations measure it solely in terms of velocity of time to market without evaluating software quality. Developers remain reticent to incorporate security and turn attention to the quality of code. As a result, software is released more rapidly but with scant regard for the quality, resulting in many applications not being ready for mass adoption.

    One Size Doesn’t Fit All With Security

    Don’t make the mistake of approaching security as a monolith. Instead, accept that it’s wide-ranging, incorporating multiple different areas spanning authentication to access control to confidentiality to integrity to non-repudiation, to name a few. Based on this broad scope, a single approach can’t hope to address all the different facets of security.

    Teams need to rethink security and look at what it means to them and what is essential to their users. This could be keeping customers’ personal identifying information confidential and establishing the types of attacks that are most likely to occur. For example, if your product is inside a corporate file, then compromised credentials and password attacks are a significant risk while denial-of-service attacks are unlikely.

    Every member of the team needs to understand security threats and techniques, so they have enough knowledge to deal with recurring issues. Threat models can include an employee unwittingly doing something wrong to trying to protect data from government-sponsored cybercrime professionals. Focusing your training on these areas will help address the vast majority of problems and ensure applications are secure. It’s vital to view security as a science rather that than an art.

    Don’t Overcomplicate Security

    Security is viewed by many as a problem that can only be solved by highly skilled and paid consultants who specialize solely in security. While there is an absolute need for these skills when reviewing architectures and carrying out audits, there is no requirement for this level of expertise when it comes to basic security checks, such as ensuring that the latest release hasn’t changed the authentication mechanism.

    The vast majority of threat models are solved using standard static and dynamic analysis tools. Once this is accepted, you can resolve 90% of security issues through a combination of tools testers and developers. This enables security to infuse every part of the development life cycle and puts an end to the practice of being an afterthought.

    Conclusion

    Once organizations incorporate these three steps in implementing DevSecOps, they can ensure that achieving security becomes a core component of software delivery. Failure to do so will see that it remains an afterthought and security vulnerabilities will continue to grow.

  • Survey Surfaces Uneven Approaches to DevSecOps

    Survey Surfaces Uneven Approaches to DevSecOps

    A ZeroNorth survey shows implementing DevSecOps is rife with questions for many organizations, with no clear answers

    There’s general agreement that digital business transformation initiatives are driving an overall acceleration in the rate at which applications are developed. At the same time, however, given the critical nature of those applications, cybersecurity has never been more of an imperative for DevOps teams. The challenge they are encountering is not so much a lack of tools to address that requirement, but rather a lack of clarity in terms of what tool to use when.

    A survey of 57 cybersecurity professionals conducted by ZeroNorth, a provider of a platform for orchestrating vulnerability scanning tools, highlights the extent of the DevSecOps challenge. The survey finds 63% of respondents said their organization currently employs six or more scanning tools. The most widely employed are network scanning (53%) and vulnerability scanning (51%). However, a quarter (25%) don’t know if their organization is using interactive application security testing (IAST), while 19% don’t know if they are using software composition analysis (SCA) tools.

    As far as DevSecOps is concerned, there’s little to no clarity in terms of where to primarily focus scanning efforts. Build/CI environments (68%) receive the most focus, but 46% are focused on scanning within integrated development environments (IDEs). Container/artifact management (67%), source code repositories (58%) and deployment (56%) all fall somewhere in between, the survey finds.

    There’s also no clear consensus on the merits of open source versus commercial testing tools Open source software (OSS) tools were identified as a priority for less than half of respondents (47%). However, 27% of respondents said they expect to begin using open source tools in 2020. Of the respondents currently employing OSS tools, 14% said believe these tools are more effective than commercial test and scan tools. Well over a third (39%) said they believe they are more effective when combined or customized. Just under a third (32%) said OSS tools are equally as effective as commercial options, while only 9% said they are less effective.

    The survey also shows disparity when it comes to the various areas that make up a digital business transformation, with the most mature being cloud migration (80%), followed by DevOps (67%), continuous integration/continuous delivery (CI/CD) (62%) and microservices (62%). Overall, 79% of respondents said they have a digital business initiative underway.

    ZeroNorth CTO John Steven said it’s clear that in many cases, the need for faster iterations of application development is outpacing the operational capabilities of IT organizations, especially when it comes to DevSecOps. Given the chronic shortage of cybersecurity professionals, there may be an average of only one cybersecurity professional for every 100 developers. Having cybersecurity professionals participate in every scrum session isn’t feasible, so there needs to be a way for cybersecurity professionals to provide guidance to developers specifically when it comes to what scanning tool should be applied and when, said Steven.

    The survey finds network (53%) and vulnerability (51%) scanning are the most broadly employed. However, that also suggests that many IT teams involved in digital business transformation initiatives are not making use of scanning at all.

    The good news is that survey respondents said identifying bugs, flaws and vulnerabilities throughout the software development life cycle (SDLC) is either “extremely” (58%) or “very” (42%) important to all participants involved. A total of 47% said it was either “extremely important” or “very important (35%) to improve visibility around operations by integrating security earlier into the software development life cycle (SDLC). However, while the DevSecOps spirit may be willing, the ability to implement best DevSecOps practices is still clearly weak.

    — Mike Vizard