Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian published an analysis of more than one billion commits to GitHub repositories that found 10 million occurrences of secrets, with one out of 10 developers exposing a secret.

    Mackenzie Jackson, a developer advocate for GitGuardian, said more than 80% of all the secrets caught by live monitoring GitHub were exposed through personal repositories, with a large share of them being corporate secrets. In fact, three million of the secrets discovered were unique instances, with 5.5 commits out of every 1,000 made exposing a secret.

    On a year-over-year basis, the report also found that the number of hard-coded secrets discovered in these repositories increased 67%. More than half the secrets discovered (56%) contained a generic password.

    There appeared to be no correlation between developer experience and the number of secrets exposed. Junior and senior developers are equally predisposed to making the same mistakes, said Jackson. The most common mistake is secrets left exposed because developers used them to simplify access to components and resources when building their applications and then forgot to remove them when the application was deployed in a production environment.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. The issue with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have issues with how secrets are managed could be staggering.

    In theory, at least, the adoption of DevSecOps best practices should be mitigating this issue, but as the volume of code stored in repositories continues to increase, it would appear more fundamental mistakes are being made. Cybercriminals, meanwhile, have a greater appreciation today for weaknesses in software supply chains, so many of them are scanning repositories for secrets that will enable them to breach an application.

    Of course, there’s a lot more attention being paid to secure software supply chains, especially in the wake of the Biden administration creating a National Cybersecurity Strategy that requires Federal agencies to, among other things, lock down software development life cycles on an end-to-end basis. Most enterprise IT organizations, if they have not done so already, are expected to follow suit.

    As a result, DevOps teams should expect to see more cybersecurity professionals focusing more on secrets management. Developers, naturally, will not want to be called out for mismanaging secrets, so over time, the overall state of application security should steadily improve. The issue, of course, is the volume of attacks against software supply chains is expected to increase. Many previous mistakes are likely to come back and haunt developers and the organizations that rely on their code and wreak havoc downstream.

  • Documentation in Agile: Challenges and Trends in 2023

    Documentation in Agile: Challenges and Trends in 2023

    Agile documentation refers to the creation and maintenance of documentation in an agile software development process. It emphasizes “just enough” documentation that is necessary for the current iteration, preferring documentation that responds to specific needs over extensive upfront documentation. The goal is to provide clear and concise information to support the development team while keeping the documentation flexible and updating it as needed throughout the development process.

    In this article I’ll present the state of Agile documentation and how it is expected to evolve in 2023 and beyond.

    What Does an Agile Approach to Documentation Look Like?

    An agile approach to documentation looks different from traditional, waterfall-style documentation practices in several ways:

    • Emphasis on just-in-time documentation: Agile prioritizes documentation that is created and updated as needed, rather than extensive upfront documentation.
    • Collaborative and iterative: Agile documentation is created and maintained through collaboration between the development team and stakeholders, with a focus on continuous improvement.
    • Flexible and adaptive: Agile documentation is designed to be flexible and adaptable, allowing for changes and updates as the project progresses.
    • Minimalistic: Agile documentation focuses on providing just enough information to support the development process, avoiding unnecessary detail.
    • User-focused: Agile documentation is centered around the needs and perspectives of the users and stakeholders, rather than the development team.

    In practice, an agile approach to documentation might involve user stories, wikis, and documentation that is integrated into the development process rather than treated as a separate task.

    7 Agile Documentation Challenges

    Teams attempting to write and update agile documentation can face several challenges, including:

    1. Balancing speed and detail: Agile documentation is meant to be lightweight, but it also needs to be detailed enough to support the development process. Striking the right balance between speed and detail can be challenging, especially as the project evolves and requirements change.
    2. Keeping documentation up to date: Agile projects are highly iterative, which can make it difficult to keep documentation up to date. Documentation that is not updated regularly can become outdated or irrelevant, causing confusion and slowing down the development process.
    3. Maintaining consistency: In an Agile development process, multiple team members may contribute to documentation, which can make it challenging to maintain consistency in style and format. This can result in documentation that is difficult to navigate and understand, which can slow down the development process.
    4. Managing collaboration: Collaboration is a key part of the Agile development process, and it is important for team members to be able to share information and feedback on documentation. However, managing collaboration effectively can be challenging, especially when team members are located in different locations or time zones.
    5. Prioritizing documentation: In an Agile development process, there is often a lot of pressure to prioritize development work over documentation. This can make it difficult to allocate sufficient time and resources to documentation, which can result in documentation that is incomplete or of poor quality.
    6. Dealing with changing requirements: Agile projects are highly iterative, and requirements can change rapidly. This can make it challenging to keep documentation up-to-date and relevant, as documentation that was created to support one set of requirements may no longer be applicable as the project evolves.
    7. Ensuring documentation is accessible: Agile projects often involve multiple team members and stakeholders, and it is important for documentation to be accessible and usable by everyone. Ensuring that documentation is stored in a centralized, easily accessible location can be challenging, especially in large or complex projects.

    Agile Documentation Trends in 2023 and Beyond

    Here are some of the key trends in Agile documentation that can help your organization improve your process and overcome the challenges above.

    Documentation Automation

    Documentation automation refers to the use of technology to automate the creation, maintenance and updating of documentation. This can involve the use of tools that generate documentation based on code, data or other sources, as well as tools that streamline the collaborative creation and review of documentation.

    In an agile development context, documentation automation can help to increase the efficiency and accuracy of documentation while freeing up time for the development team to focus on other tasks. It can also facilitate the creation of consistent, up-to-date documentation that is always in sync with the latest changes to the code or other project assets.

    Some examples of documentation automation tools include:

    • Automatic code documentation generators that extract documentation from the source code and generate reference documentation.
    • Wiki and documentation management tools that allow for the creation, editing and collaboration on documentation.
    • Automated testing and reporting tools that generate documentation on test results and project progress.

    Documentation-as-Code

    Documentation-as-code (DaC) refers to the practice of treating documentation as a first-class artifact in the software development process alongside code and other project assets. This approach aims to integrate documentation into the development process, making it easier to manage, version and maintain.

    Documentation-as-code can be achieved through a variety of methods, including:

    • Storing documentation in version control systems, such as Git, alongside the code to ensure that documentation is versioned and backed up along with the code. This is especially compatible with a GitOps development process.
    • Using markup languages, such as Markdown or reStructuredText, to write documentation, making it easier to format and display the documentation and to convert it to other formats if needed.
    • Automating the generation of documentation, such as API reference documentation, based on the code.

    The goal is to make documentation a more integral part of the development process, reducing the effort required to create and maintain documentation and improving the accuracy and usefulness of the documentation. 

    Continuous and Collaborative Documentation

    Collaborative documentation refers to the practice of involving multiple stakeholders, including developers, product owners and end users in the creation, maintenance and review of documentation. This approach emphasizes collaboration and communication as key elements of the documentation process.

    In an agile development context, collaborative documentation is seen as a way to ensure that documentation is relevant, up-to-date and meets the needs of all stakeholders. This can be achieved through a variety of methods, including:

    • User stories and other agile documentation techniques that involve end users in the documentation process.
    • Collaborative authoring and review tools, such as wikis and online document editors that allow multiple stakeholders to contribute to and review the documentation in real-time.
    • Regular retrospectives and other agile processes that provide opportunities for the development team to review and improve the documentation.

    The goal is to create documentation that is accurate, relevant and useful to all stakeholders, while also fostering communication, collaboration and continuous improvement within the development team. 

    Interactive Documentation

    Interactive documentation refers to the practice of creating documentation that is designed to be interactive, allowing users to engage with the information in a dynamic and engaging way. This can include elements such as interactive examples, simulations and tutorials, as well as tools that allow users to experiment with and explore the documentation.

    Interactive documentation can provide a number of benefits, including:

    • Improving the user experience by making the documentation more engaging and accessible.
    • Facilitating a deeper understanding of the product by allowing users to experiment with and explore the documentation in a hands-on way.
    • Improving the accuracy and usefulness of the documentation by allowing users to provide feedback and suggestions for improvement.

    Interactive documentation can be achieved through a variety of methods, including:

    • Interactive tutorials and examples that demonstrate how to use the product.
    • Simulations and prototypes that allow users to experiment with the product in a safe and controlled environment.
    • Tools for creating and maintaining interactive documentation, such as online document editors and wikis.

    Conclusion

    In conclusion, documentation is an essential aspect of the software development process, and agile development has brought about new trends in the way documentation is created, maintained and used. From documentation automation to interactive documentation, the agile approach is focused on improving the quality and usefulness of documentation while also reducing the administrative burden on the development team. 

  • Tools and Strategies to Drive a Developer Culture of Collaboration

    Tools and Strategies to Drive a Developer Culture of Collaboration

    Agile methodologies such as DevSecOps have instilled collaborative habits in many development teams. But developers still struggle to work effectively with other stakeholders in the development process. And hybrid work environments have made collaboration that much more challenging.

    In fact, across departments, employees cite collaboration issues among the chief difficulties of hybrid work, recent research shows. Workers experience deficits in team collaboration, working relationships and connection with the organization’s culture.

    A key problem for developers is connecting information silos as they interact with quality assurance (QA), site reliability engineering (SRE), product management, and lines of business. Developers need to span their own data chasms, too, as they use a wide range of siloed technology tools. In fact, 68% of developers encounter a knowledge silo at least once a week. It’s no wonder they say their two biggest challenges are fragmented information (46% of respondents) and lack of tool integrations (45%).

    There are enough stumbling blocks that your development teams probably aren’t achieving a true culture of collaboration. A culture of collaboration means that collaboration is the default mode of work–with cross-functional teams aligned, team members engaged and productive, and projects consistently achieving desired outcomes.

    As much as collaboration is built on human relationships, technology can help, especially in hybrid work environments. In particular, a collaboration platform purpose-built for technical and operations teams is fundamental to building a developer culture of collaboration.

    Automation + Integration = Collaboration

    Computers are very good at performing repetitious tasks quickly, accurately and consistently. Humans are not. They are, however, well-suited to creative activities and qualitative decisions.

    An effective collaboration platform will automate workflows so that software handles rote tasks. Team members are then freed for deep conversations that lead to better decisions and outcomes.

    Playbooks are a great way to leverage automation to improve collaboration, and your collaboration platform should include them. Playbooks are essentially digitized checklists that, with a single click, route workflows through predefined steps to complete a task.

    For example, it’s not uncommon during development for a code issue to be identified that needs to be escalated for resolution. Typically, this involves redundant texts, emails and phone calls to identify the right decision-makers, plus multiple manual steps for reviews, approvals and status updates across stakeholders and conversations.

    That can all be automated in a collaboration-platform playbook. A single click can launch an automated process to escalate the issue to appropriate team members. Workflows take place in the background, quickly and accurately, while developers continue with their collaborations.

    But developer collaboration isn’t only hampered by manual tasks. It’s also held back by a lack of integration across software tools. Developers, QA specialists, business analysts and other stakeholders use many purpose-specific technology tools. These range from Google Docs to Microsoft Excel, from Figma to Jira to GitLab. So many standalone products used by so many teams result in capability and data silos.

    A useful collaboration platform will unify these tools under a single pane of glass. That way, all team members can continue to work with software that’s purpose-built for their needs, yet all can benefit from integrated access to tools in one context. Combining disparate capabilities in a common context lies at the heart of good collaboration.

    Secure and Collaborative

    Of course, any development project involves intellectual property (IP) and other sensitive data that your organization must protect. It’s imperative that your collaboration platform provide strong security and access control.

    General-purpose collaboration products typically are cloud-based, meaning software-as-a-service (SaaS) offerings hosted by the vendor. That doesn’t always meet the needs of industries such as finance and the public sector that must comply with strict regulatory requirements for data protection.

    A collaboration platform for technical and operations teams should offer an on-premises option. That way, you can retain ownership and control of sensitive data.

    This level of security does more than simply safeguard your IP. It also encourages collaboration because team members know they can communicate and work together freely without running afoul of internal policies or external regulations. Built-in access controls should ensure that each team has access to the data it requires, but only to the data it needs to contribute to the project.

    Digital Tools for Analog Connections

    Ultimately, effective team collaboration is built on personal relationships. An effective collaboration platform will encourage human interaction through virtual check-ins, get-togethers and other digitally enabled means of “analog” connection. That could be as simple as providing a rich palette of customizable emojis that allow for personal expression and help to reveal the person behind digital communication.

    At a more sophisticated level, project retrospectives should be built into your collaboration platform to evaluate process and performance for continual improvement. Retrospectives should be blameless so all team members can benefit from learnings without feeling censured. A playbook can provide predefined guidance on meeting purpose, scope, timeframe, budget and so on. Approached this way, retrospectives provide an opportunity for team-building and strengthening of personal connections.

    Hybrid work environments for developers will continue for the foreseeable future. So will the strategic importance of developer collaboration. A purpose-built technical and operational collaboration platform can help ensure that development teams perform in a culture of collaboration and drive successful application development outcomes.

  • Balance Software Quality, Dev Speed and Cost With CI/CD

    Balance Software Quality, Dev Speed and Cost With CI/CD

    In many cases, success in the business world relies on software, be it a compelling mobile app, desktop application suite, interactive website or even an embedded system for the IoT. Because of this need, companies with mature software development processes enjoy a significant competitive advantage over those without. Part of fostering this maturity involves crafting quality software with high velocity but low costs.

    Modern software development methodologies, like Agile and its variants, play a key role in crafting applications in an effective fashion. As more companies adopted an Agile approach, the movement also fostered DevOps, a management structure combining software engineering and network administration teams while leveraging automation to build apps more quickly. In many cases, the ultimate goal for these adopters involved achieving the programming Holy Grail of continuous integration and continuous delivery (CI/CD).

    So, let’s take a closer look at continuous integration and delivery and how it helps companies successfully balance quality, speed, and cost in their software development projects. In a competitive global economy, adopting this approach remains a crucial differentiator, whether or not a business also fully adopts DevOps. In either case, understanding the benefits of CI/CD helps your software company achieve its business dreams.

    A Closer Look at DevOps

    As noted earlier, DevOps somewhat grew out of the Agile movement, but it isn’t a software development methodology in and of itself. Instead, it involves a company merging its software development team and its network administration staff largely responsible for helping the process of building applications. It increasingly leverages modern technologies like containers and virtualization for development, QA and production servers and automation for builds and testing processes.

    This organizational structure and mixture of tools combine to help companies build high-quality software with high velocity and at a lower cost. A mature community grew around DevOps, including tools, best practices, process experts and more. While DevOps originally served as the sole domain of large enterprises, now businesses of all sizes involved in software development benefit from adopting this approach.

    Defining Continuous Integration and Continuous Delivery (CI/CD)

    Continuous integration effectively automates the critical software development processes of builds and testing. It especially makes sense for shops using multiple programmers, as it works with the team’s source code version control system to ensure all programming changes are merged and remain in sync whenever a developer checks in their code.

    Any check-in typically kicks off a process where unit tests and a build are automatically run to ensure those changes don’t “break the build.” In pre-DevOps days, this tended to be a highly manual effort, leading to inefficiencies in any software development project. In short, the team only discovered any integration issues after a manual test. Automation now plays a crucial role in making this aspect of application building significantly more efficient. CI remains a critical best practice in any DevOps shop.

    Continuous delivery shares many similarities with continuous integration, especially its use of automation and the latest software development tools. However, instead of performing builds for internal developers and the QA team, CD focuses more on delivering a software product for release to a user community, customer or the public at large. Again, this is another part of the software development process that led to inefficiencies in the days before DevOps and automation.

    In terms of software development for mobile apps, CD ends up being the last part of the development process before the app gets delivered to the App Store or Google Play. It also comes into play with any fixes or feature improvements after the app is on the market. A key aspect of engendering goodwill among your customers directly relates to the speed of app improvements. Adopting a CI/CD approach plays an important role in making app changes with high velocity.

    CI/CD is the Heart of Successful Modern Software Development

    Simply stated, if your company wants to be a successful software developer, adopting both continuous integration and continuous delivery remains crucial. Following an older, manual approach causes too many bottlenecks and inefficiencies to thrive in a highly competitive industry. No matter how great your startup’s idea or app design is, failure to deliver it with high velocity ultimately results in failure. Once again, this same concept applies to fixes and feature enhancements after the app’s launch.

    At the same time, you don’t need to fully embrace the DevOps organizational structure by creating a separate team made up of software engineers and network administrators. At many startups with a small headcount, your developers might handle many of those network tasks, including managing virtual servers and containers. Hiring a network admin or two might be an unneeded luxury.

    In the end, if you want to build your startup’s app in the most efficient manner, adopting the CI/CD approach makes perfect sense. It provides speed that allows your team to effectively balance quality, speed and cost, resulting in a great app without overspending. It’s the right approach for any successful software project.

  • New Relic Adds Module to Surface Code Metrics

    New Relic Adds Module to Surface Code Metrics

    New Relic today added a free CodeStream module to its observability platform to give developers access to metrics and telemetry data that will enable them to write higher-quality code faster.

    Peter Pezaris, group vice president and general manager of strategy and experience for New Relic, said this capability is part of an effort to shift observability left toward developers to optimize code as it is written and after it is deployed.

    CodeStream surfaces metrics and telemetry data within the integrated development environment (IDE) developers use to write software. Telemetry metrics are displayed as a line of text above the code or in the debugging tool used to troubleshoot an application. Alternatively, developers can view metrics via an observability panel at the service level. They can also view performance metrics such as error rates and response times for related services.

    That approach eliminates the need to wait for IT operations teams to surface issues that usually don’t manifest until long after the code in question was originally developed, noted Pezaris.

    The overall goal is to provide development teams with frictionless access to observability data at every stage of the software development life cycle, he added. That analysis capability will result in faster mean-time-to-detection (MTTD), mean-time-to-resolution (MTTR) and, ultimately, shorter development cycles, said Pezaris.

    Organizations should also be able to reduce technical debt faster by making it easier to identify issues that, for example, adversely impact application performance, he noted. That activity can be especially challenging because developers often inherit code written by someone else that often lacks clear documentation. CodeStream makes it simpler to onboard a developer to any application modernization initiative that has been launched to reduce technical debt, said Pezaris.

    A recent New Relic survey found only 27% of respondents have achieved full-stack observability, and only 5% claimed they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found.

    On the plus side, the survey also found nearly three-quarters of respondents said C-suite executives in their organization are advocates of observability, and more than three-quarters of respondents (78%) saw observability as a key enabler for achieving core business goals. However, more than half (52%) of respondents said they experienced high-business-impact outages once per week or more, and 29% said they take more than an hour to resolve those outages.

    A full 82% of respondents said they use four or more tools to monitor the health of their systems. Only 7% said their telemetry data is entirely unified and only 13% said the visualization or dashboarding of that data is entirely unified. Nearly half of the respondents (47%) said they would prefer to have a single, consolidated observability platform, but only 2% said they currently used one tool for observability.

    Regardless of the approach to observability, it is clear that development and IT operations teams need to be looking at the same metrics and telemetry data at the same time to collaborate effectively.

  • 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.

  • Tips For Securing CI/CD Pipelines

    Tips For Securing CI/CD Pipelines

    Most development teams want to increase the pace of their software delivery. As such, continuous integration and delivery (CI/CD) has grown in importance, helping push code from build to production as seamlessly as possible. CI/CD pipelines often loop in many elements and may comprise a diverse stack of tools, automations and various languages. But because of this, the attack surface can be large. And as gaps in the CI/CD toolchain emerge, so do security concerns.

    In recent years, we’ve seen several high-profile cases where CI/CD environments were compromised. For example, take the Circle CI breach, in which a bad actor accessed Circle CI production systems. Others include the compromise of the SolarWinds build system and the Codecov breach. CI/CD security issues are alarming because so much control and automation are given to a pipeline. Unauthorized CI/CD access could be leveraged to publish malicious code or steal sensitive information.

    I recently met with Daniel Krivelevich, co-founder and CTO of Cider Security (acquired by Palo Alto Networks), to better understand the risks facing modern CI/CD. Krivelevich is a seasoned CI/CD security expert and co-author of the Top 10 CI/CD Security Risks framework, which OWASP adopted in late 2022. According to Krivelevich, there is a general lack of knowledge and visibility into these risks. “The CI/CD ecosystem as a whole is full of holes and opportunities for attackers,” he said.

    Below, we’ll review some of the risks that CI/CD pipelines face and offer general ways to mitigate some of these concerns. Hopefully, with greater security awareness around CI/CD threats, both tooling providers and users can begin to diffuse the potential of attacks against their systems.

    The Top Concerns Facing CI/CD Security

    The OWASP Top 10 CI/CD Security Risks framework covers the most impactful risks within modern engineering systems and gaps in CI/CD. It was informed by analyzing many attacks in recent years and was compiled with insights from numerous experts. Krivelevich hopes the framework will spark discussions around the mindset defenders should have when they’re looking to protect the modern engineering ecosystem. The top 10 risks are as follows:

    • CICD-SEC-1: Insufficient Flow Control Mechanisms
    • CICD-SEC-2: Inadequate Identity and Access Management
    • CICD-SEC-3: Dependency Chain Abuse
    • CICD-SEC-4: Poisoned Pipeline Execution (PPE)
    • CICD-SEC-5: Insufficient Pipeline-Based Access Controls (PBAC)
    • CICD-SEC-6: Insufficient Credential Hygiene
    • CICD-SEC-7: Insecure System Configuration
    • CICD-SEC-8: Ungoverned Usage of Third-Party Services
    • CICD-SEC-9: Improper Artifact Integrity Validation
    • CICD-SEC-10: Insufficient Logging and Visibility

    Before an organization can dissect these individual risks, however, they must overcome an even bigger problem—a critical lack of understanding regarding the CI/CD ecosystem and the many elements under the hood. Since CI/CD is not traditionally viewed as a security risk, this can result in insecure default configurations, insecure processes and systems not adopting a secure-by-design approach.

    “There’s a big gap between the level of understanding and opportunities attackers have and the knowledge defenders have over what attackers can do,” said Krivelevich. “Organizations traditionally have not been proactive enough in understanding this, unlike other elements that are more traditionally recognized as part of the attack surface. The main gap is a mindset shift.”

    Tips to Secure CI/CD

    So, knowing the above risks, what are some best practices to secure CI/CD pipelines? Krivelevich shared some tips to keep in mind.

    Bring CI/CD under the security umbrella. First, realize that CI/CD should be scrutinized. This will require an awakening in the community and more proactive effort than before. Krivelevich encouraged development teams to place it on their roadmaps and think about it.

    Map the attack surface. Before implementing security measures, you need to know what you’re protecting. Therefore, it’s a good idea to map your CI/CD environment and produce an inventory of assets. Cataloging the total surface area of dependencies and integrations is necessary to understand risks and helps mitigate CICD-SEC-10: Insufficient Logging and Visibility.

    Keep this updated regularly. Since the cadence of change is fast, teams will want constant visibility into their ecosystem and what’s under the hood. This may even lead to shadow IT, as per CICD-SEC-8: Ungoverned Usage of Third-Party Services. Therefore, Krivelevich recommended keeping a regularly updated inventory. This means continually mapping control systems, container registry artifacts, plugins and all other assets used as part of CI/CD.

    Protect the software supply chain. Many building blocks make up the modern software delivery process. But, some dependencies may be abused or contain malicious code, as per risk CICD-SEC-3: Dependency Chain Abuse. Dependencies within the CI/CD process may be prone to a host of open source vulnerabilities.

    Safeguard CI/CD credentials. CI/CD tools “possess secrets to most sensitive crown jewels in an organization,” Krivelevich explained. Therefore, access tokens and secrets related to CI/CD tools should be protected to avoid costly credential leaks. A zero-trust approach to CI/CD could help avoid CICD-SEC-2: Inadequate Identity and Access Management.

    By creating a virtual heat map of areas to address, organizations will be more informed and better equipped to assess risk. And according to Krivelevich, by implementing these best practices, defenders have a lot of power to raise security expectations in the CI/CD space. “When defenders and users become more diligent about security, the requirements from vendors will increase.”

    CI/CD is the Beating Heart, Don’t Let it Break

    “The engineering ecosystem and pipelines themselves are the beating heart of engineering,” said Krivelevich. And as this system becomes a larger part of what makes a business tick, it will be more heavily relied upon for mission-critical tasks and retaining agility.

    Yet, many building blocks comprise the contemporary software delivery process, and CI/CD pipelines can be a risky area due to the number of systems they touch. Further complicating things is the fact that the delivery ecosystem wasn’t traditionally viewed in security terms. This combination of many opportunities and limited security oversight makes CI/CD lucrative for attackers.

    Rectifying the top 10 risks is a relatively easy gap to address, said Krivelevich—what’s not so easy is the mindset shift required to take CI/CD security seriously. Organizations that invested deeply into microservices and rapid engineering processes will most likely be more susceptible to attacks, he added, since they typically use a diverse array of tools and a complex, integrated delivery process.

  • Linux Tweak Brings Big Speedup ¦ DCs in SPAAACE (Redux) ¦ Atlassian Fires 500

    Linux Tweak Brings Big Speedup ¦ DCs in SPAAACE (Redux) ¦ Atlassian Fires 500

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Intel optimizes Linux multithreaded networking, data centers in space (again), and more DevOps toolmaker layoffs. (more…)

  • Good Things Happen When DevSecOps and Cloud Collide

    Good Things Happen When DevSecOps and Cloud Collide

    The marriage of cloud and software development is arguably the heart and soul of digital transformation. Providing pathways to greater efficiencies, lower costs and greater enterprise performance, the duo is poised to fundamentally transform industries as we know them. The compounding complexities of hybrid cloud operations and software supply chains, however, have led to a greater risk of vulnerabilities, errors and attacks.

    Increasingly wrapped around microservices, containers and orchestration platforms, the complexities of cloud expansion and software development couldn’t be more intertwined or expose more complicated risks than they do today.

    Software: A World of Consistent Change

    The state of software development is one of consistent change. Whether we call it agile or adaptive matters far less than the need to infuse operations with a new mindset and culture about the need for continuous development. Increasingly that includes the infusion of security disciplines and technologies directly into the main artery of that development.

    Enter DevSecOps, an approach to software that integrates security initiatives at every stage of the software development lifecycle to deliver high-performing secure applications.

    The cause is not lost on the National Institute of Standards and Technology (NIST) and its cybersecurity center of excellence (NCCoE) which has announced a DevSecOps project dedicated to “developing and documenting an applied risk-based approach and recommendations for secure DevOps and software supply chain practices consistent with the secure software development framework (SSDF), cybersecurity supply chain risk management (C-SCRM), and other NIST, government, and industry guidance.”

    This is a far cry from software development of old. According to CTO Emeritus, Hu Yoshida, “Software, once the product of developers confined to writing long lines of code for specific applications, is now an exercise of integration – an amalgamation of third-party components provided by a variety of vendors, cloud providers, and open source software (OSS) groups. In fact, today, as much as 90% of code comes from such outlets, creating a software supply chain.”

    Although these new processes provide great advantages in terms of access to innovation and faster development cycles, the addition of external touchpoints and third-party software increases the risk of flaws, mistakes, and vulnerabilities. These risks only rise further when considering their deployment, usage, and management across complex hybrid cloud environments.

    How to Take Advantage of the Collision

    Cloud-based data is accounting for 39% of successful cyberattacks. Containerized applications, which have been a boon to both migration and management can also lead to vulnerabilities – which is fitting for security to be cited as a top concern for more than half of the organizations surveyed.

    From business continuity to business performance, organizations must begin assuming a security posture that considers the rising confluence of cloud management and software development.

    The idea is simple: You must find a way, a process, a method, and the right partners to help secure all workloads across any cloud environment, regardless of the platform or the amount of data and application real estate needed.

    By establishing this model, organizations are able to create a fundamental layer of protection against the ever-evolving threat of cybercriminals. Take one of our large banking customers, for example, who runs critical applications on AWS with stringent security and compliance requirements. We implemented a secured framework to protect their applications running on modern, cloud-native services like containers and Lambda functions using DevSecOps principles and cloud-native SIEM solutions. This enables them to scale their business in the cloud without worrying about compliance violations.

    One of our large pharmaceutical customers with a very large presence in both AWS and Azure experienced challenges keeping their cloud security posture in pace with the growing business demands on the cloud, increasing risk to the environment. By establishing a security process using cloud security posture management, we were able to significantly reduce cloud misconfigurations and auto-remediate several cloud vulnerabilities proactively to improve the security posture of the environment.

    The bottom line is that building security into the workloads will provide a fundamental layer of protection. The collision of cloud and DevSecOps is real. Organizations would be wise to realize it and take advantage of it to dramatically improve business performance and resiliency.

  • DevOps Flow: Accelerating Velocity With Software Factory Best Practices

    DevOps Flow: Accelerating Velocity With Software Factory Best Practices

    In the cloud era, senior executives are investing in key capabilities like DevOps with the expectation this will accelerate innovation and bring new digital products to market faster. To deliver on these goals, enterprise organizations seek to deploy high-quality code faster and more frequently, but they face a organizational, process and technology complexity that can hinder this objective, slowing throughput and incurring high error rates. Often when DevOps is discussed, the focus is concentrated on the technology layer, particularly the latest tools like Kubernetes, and also on the productivity of each individual developer.

    However, for many organizations, the main challenges will be with team practices and organizational models.

    Writing for DevOps.com, Mike Vizard highlighted the reality of DevOps uptake; that most adoption issues are related to organizational challenges, not technology. The top two barriers to adoption are slow processes and speed of adaptation (29%) followed by budget and funding (21%). Only 18% identified technology limitations as an issue.

    As Mike writes, it is the broader organizational transformation that is more challenging. ‘Addressing bottlenecks’ might be a function of confronting the situation of a department manager who zealously guards their turf and acts politically to resist any changes required.

    Implementing DevOps for one team is a relatively straightforward exercise, but for enterprise organizations, they face a much larger magnitude of complexity, as they typically have multiple teams spanning multiple geographies and suppliers with hundreds of developers all contributing to the same software development process.

    Therefore, a DevOps methodology that also addresses the organizational level is required, one that maps processes end-to-end and identifies the improvements needed to speed production across this entire life cycle.

    Software Factories

    Transformation leaders are turning to a ‘digital factory‘ approach to streamline this complexity into a production line model that yields consistently high throughput and quality using Lean principles derived from the manufacturing world.

    McKinsey explored the dynamics and successes of the digital factory model, a new approach to organizing digital teams. This model involves a self-organizing structure rather than rigid departmental hierarchies, and they described the KPI improvements the digital factory enables: “We see reductions in management overhead of 50% for technology teams in the digital factory, 70% in the number of business analysts needed to write technology requirements, and, as test automation becomes the norm, a drop of 90% in the number of testers. Finally, we see top engineering talent performing at eight times the level of their peers, as measured with metrics such as code commits.”

    In short, McKinsey described a development team that improves quality and finds efficiencies as a direct by-product of one that leverages the latest tools and team methods to produce better digital products faster. The concept of a ‘software factory’ is a very powerful metaphor because much of the insights are drawn literally from the world of manufacturing, where over many decades they have perfected the science of optimizing the efficiency of a production line.

    To close the loop and map these development improvements to business value, management can leverage organizational performance practices, notably Six Sigma and the theory of constraints, to define their ‘DevOps algorithms,’ a systematic formula for quantifying and improving the rate of software development throughput.

    DevOps Flow

    DevOps Flow is a methodology for implementing high-performance, cloud-centric software development based on science developed by pioneers like Toyota to optimize factory lines and apply this to software engineering.

    Organizations need the ability to measure the entire system end-to-end to understand how value flows and where it is constrained and, most importantly, to correlate those metrics with desired business outcomes. This approach allows for continuous optimization in the pursuit of delivering greater and greater value to the organization faster.

    It can be applied to speed the deployment of new software releases, notably identifying and removing constraints, reducing batch sizes and eliminating waste. These are all steps taken within manufacturing to increase production throughput and are improvements that software teams can adopt to achieve equivalent benefits.