devopsy.kinsta.cloud

Category: IT as Code

  • Cisco AppDynamics Survey Surfaces DevSecOps Challenges

    Cisco AppDynamics Survey Surfaces DevSecOps Challenges

    A survey of 1,150 large enterprise IT professionals from the AppDynamics unit of Cisco suggested application security progress is being made slowly and steadily as organizations continue to embrace DevSecOps best practices.

    The survey finds that while more than three-quarters of respondents (76%) believe that DevSecOps is essential for organizations to effectively protect against a multi-staged security attack on the full application stack only 43% reported their organization has already started to implement DevSecOps workflows while another 46% said they are currently considering making the shift.

    More than three-quarters of respondents (78%) also said a lack of a shared vision between application development and security teams presents a challenge to application security over the next 12 months. More than half (55%) said they currently considered security to be more of an inhibitor of innovation than an enabler. Nevertheless, 81% admitted a lack of application security skills and resources is now an issue for their organization, with 79% acknowledging that securing the full application stack is now a priority for their organization.

    A full 92% admitted that the rush to rapidly innovate and respond to the changing needs of customers and users during the COVID-19 pandemic has come at the expense of robust application security. Well over half of respondents (58%) also noted their organization often ended up in ‘security limbo’ because they didn’t know what security issues to focus on and prioritize. A total of 88% acknowledged their organization could be doing more to secure the full stack of modern applications across the entire application life cycle.

    Not surprisingly, 93% said it’s important to be able to contextualize security so that they can correlate risk in relation to, for example, application performance, end user experience and business metrics. However, more than two-thirds (68%) reported that their current security solutions work well in silos but not together. A total of 85% stated that cultural changes to support the shift to a DevSecOps approach are important to improve application security.

    AppDynamics Executive CTO Gregg Ostrowski said it is apparent organizations are still wrestling with not just application security technologies but also people and process issues. The most critical issue is to knock down the silos that exist in organizations that often result in one team demonizing another, he added.

    Overall, application security is becoming more challenging as the attack surface expands. A full 89% of technologists reported that their organization experienced an expansion in its attack surfaces over the last two years, with almost half (46%) noting that this expansion is already increasing cybersecurity challenges. One of the primary drives of that expansion as been the rise of the internet-of-things (IoT) applications (59%), rapid adoption of cloud computing platforms (56%) and digital business transformation initiatives (51%).

    On the plus side, more than three-quarters of respondents (76%) said they believe artificial intelligence (AI) will play an increasingly important role in addressing application security challenges. The issue, of course, is how soon those advances might be made at a time when attacks against software supply chains are clearly on the rise.

  • New Relic Bolsters Observability Platform

    New Relic Bolsters Observability Platform

    New Relic has updated its observability platform to include the ability to better detect and track errors in addition to monitoring vulnerabilities.

    At the same time, an instance of the New Relic observability platform that runs natively on the Microsoft Azure cloud platform is now also generally available.

    Manav Khurana, general manager for observability product and chief growth office for New Relic, said the alliance will enable Microsoft Azure customers to consume New Relic as part of their existing Microsoft Azure services contract.

    New Relic already provides an errors inbox to track issues, but is now adding a tool to track the impact an error might have by correlating data across traces and logs. The company has also integrated its platform with Slack to make it simpler for IT teams to generate alerts when vulnerabilities are introduced into codebases and manage errors more collaboratively.

    Similarly, New Relic is also looking to foster greater collaboration between software engineering and cybersecurity teams. A New Relic Vulnerability Management tool with no additional configuration required captures security signals generated via the company’s Telemetry Data Platform in a way that can be analyzed using an interactive application security testing (IAST) tool that New Relic gained with its acquisition of K2 Cyber Security. Additional IAST capabilities available in preview include the ability to leverage a patented deterministic technique to identify and provide automated vulnerability validation that highlights a proof-of-exploit.

    The overall goal is to provide more visibility and context for organizations that are implementing best DevSecOps practices, said Khurana.

    It’s still relatively early days as far as the integration of observability platforms into DevOps workflows is concerned. A recent survey conducted by New Relic found most organizations don’t expect to have robust observability practices in place by 2025. While most organizations have tools to monitor predefined metrics today, there is a significant gap between observability platforms that enable IT teams to determine the root cause of an IT issue and monitoring platforms that generate an alert whenever a threshold is exceeded.

    In fact, many organizations have too many monitoring tools that often surface conflicting or redundant alerts, noted Khurana.

    One way or another, more codebases are being instrumented. As that process continues to evolve, the agents embedded in that code make it simpler to collect the logs and traces needed to advance observability. The challenge, as always, is that it takes time for the number of fully instrumented applications to exceed the number of legacy applications that are either partially instrumented or not instrumented at all.

    As IT environments become more complex, the need for observability is becoming much more pressing at a time when most IT teams are more short-handed than ever, noted Khurana.

    Regardless of approach, there’s no doubt that observability, with patience, will impact the management of IT for the better.

  • Atlassian Extends Automation Framework’s Reach

    Atlassian Extends Automation Framework’s Reach

    Atlassian this week extended its namesake automation framework to include its Confluence collaboration software. In addition, it’s now possible to automatically create bi-directional branches in Bitbucket, GitHub or GitLab platforms from within the company’s Jira project management application.

    At the same time, it’s now possible to automatically generate feature flags from within Jira through integration with the feature management platform created by LaunchDarkly and automate alert and incident responses stemming from the Amazon Web Services (AWS) cloud.

    Dilani Kahawala, head of product for the automation platform at Atlassian, said these extensions to the Atlassian Automation framework are part of a larger ongoing effort to remove the silos within software engineering teams and the rest of the business.

    DevOps teams, for example, will now be able to expand the number of those automated actions being taken because change requests can be automatically created. Atlassian estimated that IT teams will spend 25% less time managing change requests and save 115 hours per month.

    To save more time, templates that automatically create Wiki pages in Confluence can be spun up at the completion of every sprint.

    Since it first launched for Jira in 2020, Atlassian claims more than 10 billion automated actions have been executed across the Atlassian platform.

    Kahawala said as more organizations realize how dependent they are on software to drive revenue, the need to close the divide between software engineering teams becomes much more pressing. She noted that changes to the timetable for one project can have a cascading effect across the entire business. At a time when organizations are counting on digital business transformation initiatives to remain competitive, the speed at which organizations share updates across silos is critical, said Kahawala.

    At the same time, organizations are also striving to become more productive in an uncertain global economy. Automating rote tasks makes it possible for development teams to spend more time writing code, added Kahawala.

    Less clear right now is whether businesses can absorb the pace of change that is enabled by modern software development. Historically, business leaders complained that their dependency on IT was holding the business back because it took too long for IT teams to implement changes. Today, however, many organizations routinely deliver code updates to mission-critical applications daily. While not every delivery may involve a major new update, it’s apparent that the pace of innovation is now occurring at speeds many organizations find challenging to absorb.

    As organizations continue to adopt best DevOps practices, the pace of innovation is only going to accelerate further. The challenge—and the opportunity—is to ruthlessly eliminate as many manual tasks as possible to accelerate the pace of innovation. After all, software engineering pros have better ways to spend their time than manually creating yet another branch in a continuous integration/continuous delivery (CI/CD) platform or, worse yet, reenter data into a project management application.

    Join the makers of Jira for a brand-new (free) Agile & DevOps event. Atlassian Presents: Unleash is designed to help your team collaborate from discovery to delivery to running great software. Get first access and “cheat codes” to the newest Jira Software features and products from Atlassian; network with peers, industry experts, and Atlassian product leaders; and solve real-life challenges around your Jira and toolchain configuration and workflow. Live in Berlin or digitally on February 9. Register for free.

  • Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off

    Software Supply Chain Security Debt is Increasing: Here’s How To Pay It Off

    Last year, the world woke up to the software supply chain dilemma. We saw a spike in attacks as hackers sought to exploit known and unknown vulnerabilities within dependencies. There is also the chance of typosquatting, and malicious code commits to consider. Such supply chain attacks have increased by a shocking 742% over the past few years.

    It’s easy to let software security debt accumulate, as it’s cumbersome to stay on top of frequent updates — especially when new releases cause breaking change. Furthermore, companies might unknowingly collect security debt by hastily looping in projects whose origin is unknown. Plugging these gaps can bring a high burden down the road, which too often falls on the shoulders of developers to manage.

    I recently reconnected with Dan Lorenc, founder and CEO of Chainguard, to discover why risks in the software supply chain contribute to increased security debt and how organizations can proverbially pay it off. Lorenc is a key figure behind Sigstore, the open source utility built to verify the provenance of open source packages. Below, we’ll consider the state of software supply chain security and examine some modern solutions that lessen its severity.

    Why is Supply Chain Security Debt Rising?

    Modern software ecosystems are an intricate mosaic of dependencies, and supply chain security concerns often arise at the cracks between them. “It’s about the gaps and hand-off points between individuals in the software life cycle,” said Lorenc. Since these hand-off points can threaten systems at large, they can accumulate considerable security debt if left unguarded.

    Another reason why security debt is increasing, said Lorenc, is that fixing issues is rarely incentivized—it’s always thought of as “someone else’s problem.” Minimizing this debt will require organizations to change this mindset and follow modern security best practices, like implementing multifactor authentication infrastructure and more frequent code reviews. It will also take a coordinated effort from package managers to integrate tooling that helps verify the legitimacy of packages, said Lorenc.

    Solutions to Reduce Software Supply Chain Security Debt

    Automated Vulnerability Scanning

    In addition to advancing internal culture toward greater security awareness, organizations will benefit from automation that enhances the discovery of vulnerabilities. Because when a severe incident like Log4j hits the presses, it’s a mad scramble to respond. Even a year later, one in four downloads still possesses the infamous vulnerability.

    Integrating automated security scanning is the first step to knowing how these incidents impact your security posture. A tool like Snyk can do a great job of surfacing known vulnerabilities and finding where they lie within your software stack and provide remediation advice. Continually checking for updates can also help pay off security debt “as you go” instead of upgrading everything all at once, says Lorenc. But although scanning tools are essential for increasing visibility, they don’t address the root cause of why they are vulnerabilities in these packages in the first place, says Lorenc.

    Checking Transitive Dependencies

    Reports find that 95% of vulnerabilities stem from transitive dependencies. These are dependencies that are buried deep within the dependency tree of another package. And depending on the programming language, they’re not always that visible. The combinatory effect of transitive dependencies can lead to exponentially more vulnerabilities and issues if not carefully tracked. And since they’re running locally with the same privileges as your other packages, you shouldn’t treat these vulnerabilities any differently, said Lorenc. “You need to realize they can affect your application in the same way.”

    Validating The Source

    The link between the package manager and the source code is a frail area that warrants additional verification. Social engineering tricks can effectively trick users into downloading insecure packages that appear safe at the outset yet hide corrupt code. Or, account takeovers can result in attackers inserting malicious code into commonly used open libraries. Package managers often host built versions and forked versions of software produced by the community on GitHub, yet do not validate a clear link to the original repository. This gap heightens the chance for a malicious package to slip through the cracks, says Lorenc.

    This is something that Sigstore, the open standard for signing, verifying and protecting software, aims to accomplish. In mid-2022, Sigstore was implemented within Kubernetes, signaling the adoption of Sigstore as a standard throughout the open source ecosystem. It’s also been adopted by Npm and PyPI and Maven Central will soon support Sigstore as well, said Lorenc. Although some of these moves have received pushback from developers, Lorenc argued that such verification is necessary to help link packages to their source and increase credibility for open source dependencies.

    Chipping Away At Security Debt

    Like technical debt piles up over time, security debt can quickly rise if left unchecked. Chipping away at increasing software supply chain security debt will likely require a “pay as you go” approach wherein developers continuously scan and update their dependencies. One good sign is that people are paying more attention to risks latent within their code, and the industry is discovering and sharing more potential vulnerabilities before they are exploited.

    “Security has advanced, and there are common best practices across the industry,” said Lorenc. But if these practices aren’t followed, it could bring dire consequences for the organizations and the industry as a whole. And although Sigstore can help bridge the disconnect between the package managers and the source code, there are plenty of other techniques to help improve a security footprint for open source software and cloud-native infrastructure. For example, SLSA and greater use of SBOMs can help address security debt more holistically.

    The software supply chain security dilemma is an advanced topic that requires a coordinated effort from various stakeholders to remedy. The important takeaway is to stay positive, see the debt, and pay it off incrementally, says Lorenc.

  • Microsoft Outage Outrage: Was it BGP or DNS?

    Microsoft Outage Outrage: Was it BGP or DNS?

    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: All of Microsoft’s cloud services go down, everywhere except China. Redmond’s IaaS, PaaS and SaaS—including GitHub—were dead for several hours, and are still running unreliably—despite Microsoft saying it’s fixed the problem. (more…)

  • Deploying a Service Mesh: Challenges and Solutions

    Deploying a Service Mesh: Challenges and Solutions

    A service mesh is a dedicated infrastructure layer that enables communication between microservices in a distributed application. It helps to abstract the underlying communication infrastructure, such as network protocols and load balancing and provides a consistent interface for microservices to communicate with each other.

    In a service mesh, each microservice in the application is represented as a “service” within the mesh, and the mesh acts as a proxy between the services, routing requests and responses between them. It also includes a control plane, which manages and configures the proxy instances and provides observability and monitoring capabilities for the services.

    Some of the benefits include:

    • Improved observability: A service mesh provides visibility into the communication between microservices, which can be helpful for debugging and monitoring the performance of the application.
    • Resilience: It can help to make microservices more resilient by providing features such as retries, timeouts and circuit breakers, which can help to prevent cascading failures.
    • Security: A service mesh can help to secure communication between microservices by providing features such as mutual TLS (mTLS) and rate limiting.
    • Ease of use: It provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications.

    Why is a Service Mesh Important?

    A service mesh is important because it helps to abstract the underlying communication infrastructure for microservices-based applications, which can make it easier for DevOps teams to build and manage these types of applications.

    One of the main benefits is that it provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications. For example, a service mesh can provide features such as load balancing, retries and timeouts, which can be useful for ensuring the resilience and reliability of the application.

    It can also help to improve observability for microservices-based applications by providing visibility into the communication between the microservices. This can be helpful for debugging and monitoring the performance of the application, which can, in turn, make it easier for DevOps teams to identify and resolve issues more quickly.

    What are the Main Deployment Challenges?

    There are several key challenges that a DevOps organization may face:

    • Complexity: Service meshes can be complex to set up and manage, especially in large, distributed applications. This can make it challenging for organizations to implement and ensure that it is configured correctly.
    • Operational overhead: Service meshes can add a layer of complexity to the application stack, which can increase the operational overhead of managing the application. This can be especially challenging for organizations that are not used to operating one.
    • Cost: While service mesh software is typically open source, the need to run a sidecar container alongside every container can increase the compute capacity needed to run a Kubernetes cluster.
    • Integration with existing systems: They can be difficult to integrate with existing systems and processes, especially if the organization has not previously used a service mesh. This can make it challenging to get the full benefits.
    • Lack of expertise: Service meshes are relatively new technologies, and there may be a lack of expertise within the organization. This can make it challenging for organizations to get started and ensure it is used effectively.
    • Performance overhead: Service meshes can add a performance overhead to the application as they introduce an additional layer of proxying between microservices. This can make it challenging to ensure that the application is performant and scalable.

    Best Practices to Ease Service Mesh Pain

    Here are a few best practices that can turn service mesh deployments from a pain to a pleasure.

    Use Configuration-as-Code in a GitOps Approach

    Using configuration as code in a GitOps approach is a best practice to improve reliability and maintainability.

    GitOps is a way of managing infrastructure and applications using Git as the single source of truth. In a GitOps approach, all configuration and deployment information is stored in Git, and changes to the infrastructure and applications are made by committing code changes to Git.

    Using configuration-as-code in a GitOps approach can help to improve the reliability and maintainability of the service mesh in several ways:

    • Version control: Storing configuration-as-code in Git allows you to track changes to the service mesh configuration and roll back changes if necessary. This can help improve the service mesh’s reliability by making it easier to identify and fix issues.
    • Collaboration: Git allows multiple people to work on configuration at the same time, which can make it easier to collaborate on changes and ensure that the service mesh is properly maintained.
    • Automation: GitOps approaches often use automation tools, such as continuous integration and delivery (CI/CD) pipelines, to automatically deploy changes to the service mesh when code is committed to Git. This can make it easier to manage and maintain and can help to improve its reliability by reducing the risk of errors.

    Focus On Developer Experience

    Ensuring a positive developer experience is a best practice because it can help to improve the productivity and effectiveness of the development team. A positive developer experience means that developers can easily understand and use the service mesh, and that it does not introduce unnecessary complexity or frustration into their workflow.

    Here are some ways to improve the developer experience:

    • Provide clear documentation: It is important to provide clear and comprehensive documentation on how to use the service mesh, including examples and tutorials. This will make it easier for developers to understand and use.
    • Integrate with existing tools and processes: The service mesh should integrate seamlessly with the existing tools and processes that the development team is already using. This will help to minimize disruptions to the team’s workflow and make it easier for them to work with.
    • Provide support and training: It is important to provide support and training to help developers understand and use the service mesh effectively. This can include online resources, in-person training, and support from the vendor.

    Reduce Costs With Low-Cost Cloud CPUs

    A service mesh increases the cost of an entire containerized deployment because it requires deploying a sidecar container alongside all workloads. When running on Amazon Web Services (AWS), the AWS Graviton processor can ease deployment by reducing the cost of running service mesh infrastructure.

    The AWS Graviton processor is a custom ARM-based processor designed specifically for use in Amazon Web Services (AWS) environments. It is optimized for running workloads commonly found in the cloud, such as microservices and containerized applications.

    Using the AWS Graviton processor can help to reduce the compute costs of a service mesh because it is generally less expensive than other processors, such as Intel Xeon processors. The AWS Graviton processor is also designed to be highly efficient, which can help reduce the service mesh’s overall resource utilization. This can help to reduce the cost.

    Choose the Right Control Plane

    Choosing the right control plane is a best practice because it can impact the performance, reliability and maintainability of the service mesh. The control plane is the central component that manages the proxy servers and enables you to configure and monitor the communication between microservices.

    Here are some considerations for choosing a good control plane:

    • Compatibility: It is important to choose a control plane that is compatible with the rest of the service mesh infrastructure, as well as with the application and its dependencies. This will ensure that the control plane can operate effectively and support the needs of the application.
    • Performance: The control plane should be able to handle the traffic and data volumes of the application without experiencing performance degradation. It should also be able to scale up or down as needed to meet changing demand.
    • Reliability: The control plane should be reliable and able to withstand failures without interruption. It should also provide features such as circuit breaking, retries and timeouts to help improve the resiliency of the service mesh.
    • Ease of use: The control plane should be easy to use and understand, with clear documentation and a user-friendly interface. This will make it easier for the DevOps team to manage and maintain the service mesh.
    • Integration with other tools: It is important to consider how the control plane integrates with other tools and systems, such as monitoring and logging tools, and how it can be integrated into the overall workflow of the organization.

    Conclusion

    In conclusion, deploying a service mesh can be a complex and challenging process, but it can also provide significant benefits in terms of improving the reliability, scalability and security of a cloud-native application. 

    Some of the key challenges include complexity, operational overhead, integration with existing systems, lack of expertise and performance overhead. 

    To overcome these challenges, it is important to choose the right service mesh, use configuration-as-code in a GitOps approach, choose the right control plane and ensure a positive developer experience. By addressing these challenges and following best practices, organizations can successfully deploy a service mesh and reap the many benefits it has to offer.

    Image Source 

     

  • State of DevOps Report Finds a Rise in Platform Engineering

    State of DevOps Report Finds a Rise in Platform Engineering

    The speed of software development velocity is increasing, and to enable this, platform engineering is emerging to evolve the DevOps practice. Interest in platform engineering is rising—so much so that Puppet emphasized platform engineering in its 2023 State of DevOps Report.

    A whopping 94% of respondents agreed that platform engineering is helping their organizations better realize the benefits of DevOps. The move toward platform engineering has increased over time, bringing benefits such as increased release velocity, reliability and efficiency.

    Below, we’ll highlight some of the key takeaways from the report. We’ll define what platform engineering is and highlight its benefits. We’ll also consider obstacles on the path to embracing a platform-based development culture.

    Platform Engineering Supplants DevOps

    DevOps has been in use for a decade or more at most institutions, maturing steadily with new automation and infrastructure abstraction. The latest evolution of DevOps is a practice known as platform engineering—51% of organizations have already adopted this practice within the last three years and 93% said it’s a step in the right direction.

    Platform engineering is the discipline of designing and building self-service capabilities to minimize cognitive load for developers and to enable fast-flow software delivery.

    In essence, platform engineering is the process of creating standardized, self-service infrastructure that helps developers get up and running quickly. These self-service platforms typically handle capabilities like deployment (43%), operation of infrastructure (43%), monitoring production applications (42%) and security and compliance (42%).

    These shared internal platforms are maintained by a central platform team that embraces a product mindset to iterate the technology based on user feedback.

    State of Platform Engineering

    Platform engineering is relatively new— 27% of platform teams have formed within the last two to three years. Notably, big tech companies hopped on the bandwagon years ago, and non-tech companies are now following. Regardless, 70% believed their timing was “just right.”

    The goals of a platform engineering team are numerous. According to the Puppet report, 54% said problem-solving is the top goal. This is followed by educating and empowering developer teams (47%), setting best practices (46%) and optimizing iteration (44%). A platform engineering team’s scope of work is primarily focused on automating workflows and building and managing infrastructure.

    The ‘correct’ number of internal platforms is a moving target. The majority of organizations (57%) have between two and four platforms, and 30% have five or more internal self-service platforms. This demonstrates that although platform engineering is somewhat centralized, it’s also flexible to the needs of an organization.

    Benefits and Hurdles

    So, what are some benefits as opposed to traditional DevOps? Well, the most common benefit is improved system reliability, at 60%. This tracks, as a standardized platform could reduce human error and missteps in the development workflow. Following this benefit is improving efficiency (59%), speeding up delivery time (58%) and improving workflow and process standards (57%).

    The most common driver of adoption is increasing the speed of delivery. Slight more than half of respondents (51%) said development speed has somewhat increased since the inception of the platform team, and 42% say it’s increased by “a great deal.” Other top drivers include the need to scale, free up engineering time, control infrastructure spending and avoid duplication across teams. Those with more mature adoption tend to be more satisfied with the result, indicating that results increased over time.

    Of course, no new technological introduction comes without its hurdles, and platform engineering is not immune from certain pain points. For example, 34% said that cycle time is slower than expected. This might be due to nascent industry adoption and a lack of best practices.

    Just under one-third (32%) also noticed resistance to platform team adoption, and 32% reported a lack of communication around changes. Organizations will likely have to increase transparency and reduce siloing to encourage productive platform adoption that satisfies the needs of various stakeholders.

    According to the report, product management skills can help realize these goals. Some of the most fundamental product management skills here include strong communication skills (61%), problem-solving expertise (60%) and the ability to foster collaboration (54%). Many companies will also have to convince senior management to invest in platform engineering—nearly half agreed that senior management doesn’t yet understand its value.

    Future Outlook

    Confidence around platform engineering is increasing, especially for teams with mature DevOps approaches. As a result, the practice will likely gain more traction in the coming year—71% of respondents reported their firm plans to hire people with platform engineering experience over the next 12 months.

    Over the next year, organizations that adopt the practice will want to increase awareness of platform capabilities and set expectations across the organization. This will also include setting governance policies and satisfying the needs of specific developers, departments and the organization as a whole.

    Above, we’ve scratched the surface of the current state of platform engineering, its benefits and its pain points. For plenty of other insights, you can pick up a copy of The State of DevOps Report 2023: Platform Engineering Edition from Puppet by Perforce here.

  • Why Can’t We Be Friends? Improving Developer-Tester Alignment

    Why Can’t We Be Friends? Improving Developer-Tester Alignment

    Sometimes coding can be such an art form that it deserves to be a masterpiece in a museum. Developers are proud of their code—at least until the so-called art critics (aka testers) step in with their critiques. And then the rapport can swiftly become as messy as a painter’s palette. You have probably seen this scenario play out time and again at your organization. In the mad dash of a software release, the relationship between developers and testers can quickly become stressful and strained. And while your teams know about helpful tools that can streamline collaboration, you may not be aware of other steps you can take that go beyond the screen to ensure an even better developer-tester relationship.

    Full disclosure: At my organization, we’re in the software testing business and we’re not playing favorites when it comes to testers versus developers. We’ve just learned a thing or two about what makes a happy collaboration for all the parties involved. And we’ve seen that organizations that improved their developer-tester alignment not only accelerate a smoother release cycle but also leave no hard feelings on the table for the next time.

    Leave the Keyboard, Take the Cannoli

    Developers and testers will find that if they move their interactions away from the keyboard, they’ll discover that sweet spot of improved communication and transparency. Whether at your daily standup, over a cup of coffee or by simply picking up the phone, spending a few minutes chatting can address miscommunications before they become major problems that can delay your release.

    If something seems off, bring it up as early as possible. Take, for example, the classic case of missed requirements. One of our customers recently shared a story with us that really hit home. At the top of the sprint, a particular user story included only seven acceptance criteria–which caught the attention of one of the developers. He pointed it out in a conversation with the testers and business analysts on the project. Together, the group identified four additional acceptance criteria missed during the initial scoping.

    Without that conversation, the team would have assumed those seven acceptance criteria were the only ones that tests needed to be written against. A number of defects would have slipped into production, and it wouldn’t have been the software developers’ or the testers’ fault. Instead, the testing team realized significant gaps in test coverage and their test plan grew from seven to 40 test cases.

    The takeaway? Make sure that developers, testers and business owners are clear on how business requirements align with what software developers plan to build, as well as how testers plan to test against them. Have this conversation before the sprint begins—and don’t forget the cannoli.

    You Complete Me: In-App Test Management

    “I love documenting test plans in spreadsheets!” said no one, ever. All that manual work just takes time, introduces errors and leads to frustrations among developers and testers who have to go digging for the information they need. Adding a Jira app, for example, for test management can be the key to completing the alignment between teams.

    In-app test management gives both teams real-time data for decision-making and collaboration with built-in reporting on testing. That means that software testers can fully plan, design, track, and analyze testing activity within the same workflows that developers and testers are already using. For developers, there’s no need to ask testers for status updates or results. And testers can quickly see how tests align to requirements, which helps them brainstorm additional tests and provides developers better context and information to develop around.

    The cherry on top? The entire team can maintain true traceability between requirements and test coverage, which both minimizes finger-pointing and ensures that everyone has a clear picture of what’s required before the release is ready to ship.

    There’s an Awful Lot you can Tell About a Person by Their Software

    As Mama always said, shoes tell where someone is going and where they’ve been (mic drop, Forrest). By talking the talk and walking the walk in a counterpart’s shoes, developers and testers can better understand each other’s worlds. In-app test management can give developers a window into the tester’s thought process, because it shows them not only test status but also how a tester arrived at a particular defect. After gaining this familiarity, developers may be more open to inviting testers to sit in on traditionally dev-focused activities.

    Take unit testing or code reviews, for example. Most QA teams tend to steer clear. But by joining in, testers can ask questions and grasp which pieces will be validated at the unit, integration, and functional levels. A bonus is that testers get an inside look at the codebase, helping them develop more technical knowledge, as well as collaborate with developers on how the unit tests they plan to run–gasp!–fit into the overall picture of quality and release readiness.

    Remember, the true purpose of QA is to provide information that verifies that the application works well enough to be put in front of customers. By understanding the testing that’s going on at the unit level, QA can be more efficient by focusing on what’s not being covered in unit tests.

    The result? A more cohesive, effective test plan and a release that the whole team–developers, testers and business owners–can be proud of. In other words, a release masterpiece.

  • Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta today made generally available an Actions Integration capability that makes it possible to integrate third-party tools without having to write any code.

    Shiven Ramji, chief product officer for Okta, said this no-code integration capability for the Okta Customer Identity Cloud extends a simpler approach for managing secrets that is invoked via an application programming interface (API).

    At a time when more responsibility for application security is being shifted left toward developers, the Okta Customer Identity Cloud is gaining traction as an alternative for managing secrets more securely, noted Ramji. Rather than developers attempting to manually verify the identity of end users, it becomes easier to manage identity flows within the context of a larger application development workflow using a cloud service, he added.

    In addition to giving developers access to Actions Integration, Okta is also making third-party integrations developed by partners available via the Auth0 Marketplace. The goal is to encourage providers of application development tools to build integrations that development teams can simply download when needed, said Ramji.

    It’s not clear how much influence developers are exerting over how identity is managed as more organizations embrace DevSecOps best practices for building and deploying applications. Regardless of approach, the overall state of application security should continue to improve as developers embrace new methods of managing identity within their applications. One of the issues that frequently creates a security breach is when developers forget to remove secrets created during the application development process before an application is deployed in a production environment. Cybercriminals today routinely scan for secrets that have been inadvertently stored as text within an application.

    Lees clear is the degree to which developers may opt to update existing applications to take advantage of identity management services that can be invoked via an API or whether they will opt to switch to a cloud service for only new applications.

    One way or another, organizations of all sizes will need to find a way to make it easier for developers to manage identities across multiple applications. There is often a tendency to ascribe responsibility for managing identities to development teams without always providing access to a set of tools to manage the process. In about half of the instances in which organizations adopt Okta Customer Identity Cloud, the decision is made by developers, said Ramji. Many of those developers discover the Okta service when they are building a proof-of-concept for their application, he added.

    The other half of the time the decision is made by more senior leaders on behalf of an entire development team, said Ramji. In some of those cases, organizations are even going to far as to create a team of specialists for managing identities across a portfolio of applications, he noted.

    The core issue, as always, is determining how much time and effort developers will want to spend on identity management versus writing business logic code. All things considered, most developers are going to find it a lot more convenient to invoke an API to access a cloud service versus setting up and maintaining a vault full of application secrets on their own.

  • AppSec in the Cloud: What DevOps Teams Should Know

    AppSec in the Cloud: What DevOps Teams Should Know

    Cloud application security refers to the measures and controls that are put in place to protect cloud-based applications and data from cyberthreats, unauthorized access and data breaches. These measures can include technical controls such as encryption, access controls and secure networks, as well as operational controls like policies and procedures for managing and securing data in the cloud.

    Cloud application security is important because it helps to ensure the confidentiality, integrity and availability of data and applications in the cloud. It is especially critical for organizations that store sensitive or regulated data in the cloud, as a security breach could have serious consequences for the organization and its customers.

    There are many different approaches to cloud application security, including the use of security protocols, identity and access management (IAM) systems and security information and event management (SIEM) tools. Some organizations may also choose to use cloud security platforms, which provide a range of security services and tools that can be used to protect cloud-based applications and data.

    How DevOps Secures the Cloud

    DevOps is a software development approach that aims to optimize the collaboration and communication between development and operations teams to deliver software more quickly and efficiently. It involves using automation, continuous integration and delivery and other tools and practices to streamline the software development process.

    Cloud security operations, or CloudSecOps, refers to the practices, processes and tools used to secure and manage cloud-based applications, systems and data. CloudSecOps is a key aspect of DevOps, as it helps to ensure that cloud-based applications and systems are secure and compliant, while also allowing for rapid deployment, scaling and management of applications in the cloud.

    There are several key ways that CloudSecOps can be implemented in the cloud as part of a DevOps approach:

    • Automated security testing: CloudSecOps can be implemented using automated security testing tools, which can be integrated into the CI/CD pipeline to continuously test and validate the security of code changes.
    • Identity and access management: CloudSecOps involves using identity and access management (IAM) systems to control and monitor access to cloud-based resources. These systems can be integrated into the DevOps process to ensure that access to cloud-based systems is properly managed and secured.
    • Security as Code: CloudSecOps can be implemented using security-as-code practices, which involve writing security policies and controls in code and integrating them into the CI/CD pipeline. This allows organizations to automatically enforce security controls as part of the software development process.

    4 Cloud Application Security Best Practices

    Understanding and Monitoring Dependencies in Cloud Applications

    Application dependency mapping is a technique that can be used to visualize and understand the dependencies between different components of a cloud application. This can help organizations identify and manage the risks associated with dependencies and ensure that all application components are up-to-date and secure.

    There are several key benefits to using application dependency mapping as a cloud application security best practice:

    • Improved visibility: Application dependency mapping provides a clear and comprehensive view of the dependencies between different components of the application, which can help organizations to better understand the risks associated with these dependencies.
    • Improved risk management: By understanding the dependencies between different application components, organizations can identify and prioritize the most critical dependencies and take steps to mitigate any associated risks.
    • Improved security: By regularly monitoring dependencies for updates and vulnerabilities, organizations can ensure that all application components are secure and up-to-date.
    • Improved compliance: By understanding and managing the dependencies between different application components, organizations can ensure that they meet compliance requirements for storing and processing data in the cloud.

    Cloud Database Security

    Cloud database security is a critical aspect of cloud application security, as it involves the measures and controls that are put in place to protect data stored in the cloud from cyberthreats, unauthorized access and data breaches. 

    Ensuring the security of cloud-based databases is important because these systems often store sensitive or regulated data. A security breach could have serious consequences for the organization and its customers.

    There are several key best practices for ensuring the security of cloud-based databases:

    • Encryption: Encrypting data at rest and in transit can help to protect against unauthorized access to data stored in the cloud.
    • Access controls: Implementing fine-grained access controls can help to ensure that only authorized users have access to data stored in the cloud.
    • Security monitoring: Monitoring for security events and anomalies can help to identify and respond to potential threats to data stored in the cloud.
    • Compliance: Ensuring that cloud-based databases meet compliance requirements for storing and processing data is an important best practice to protect against data breaches and ensure regulatory compliance.

    Apply Cloud Governance Policies

    Cloud governance refers to the practices, processes, and controls used to manage and govern the use of cloud-based resources and services. Some of the key ways that organizations can apply cloud governance policies to improve the security of their cloud-based systems include:

    • Establishing policies for access and use: Organizations can establish policies that define who has access to cloud-based resources and how they can be used. This can help to ensure that access to sensitive data and systems is properly controlled and monitored.
    • Implementing security controls: Organizations can implement security controls such as encryption, access controls and secure networks to protect data and systems in the cloud.
    • Ensuring compliance: Organizations can establish policies and procedures to meet compliance requirements for storing and processing data in the cloud.
    • Monitoring and auditing: Organizations can establish policies for monitoring and auditing the use of cloud-based resources to ensure that they are being used in accordance with established policies and procedures.

    Identify, Categorize and Protect Sensitive Data Stored in the Cloud

    Sensitive data refers to information that is highly confidential or regulated and that requires special protection to ensure its confidentiality, integrity, and availability. There are several key steps that organizations can take to identify, categorize and protect sensitive data stored in the cloud:

    1. Identify sensitive data: The first step is to identify the sensitive data stored in the cloud. This may include personal data, financial data, intellectual property and other types of sensitive information.
    2. Categorize sensitive data: Once the sensitive data has been identified, it is important to categorize it based on its level of sensitivity and the potential risks associated with it. This can help organizations to prioritize the protection of different types of sensitive data.
    3. Protect sensitive data: There are several different measures that organizations can take to protect sensitive data stored in the cloud, including encryption, access controls and secure networks. It is also important to implement policies and procedures to ensure that sensitive data is handled and processed securely.

    Conclusion

    In conclusion, application security in the cloud is a critical concern for DevOps teams, as it involves the measures and controls that are put in place to protect cloud-based applications and data from cyber threats, unauthorized access, and data breaches. 

    To ensure the security of their cloud-based systems, DevOps teams should implement a range of best practices, including understanding and monitoring dependencies, implementing security controls, managing identities and access, and ensuring compliance. By following these best practices, DevOps teams can help to ensure the security and integrity of their cloud-based systems and protect against potential threats.