devopsy.kinsta.cloud

Tag: devsecops

  • JFrog’s swampUP 2023: Ready for Next 

    JFrog’s swampUP 2023: Ready for Next 

    In the ever-changing landscape of technology and software development, staying ahead is essential. JFrog has led a pioneering effort to transform DevSecOps since its founding in 2008. Micheline Nijmeh has been chief marketing officer for the past three years, and in that time, she said JFrog has steadily tackled critical issues across the industry.

    “JFrog really started off addressing a pain point, which involved being a software supply chain platform that simplifies the DevSecOps processes by automating the entire software build and release process for large enterprises,” Nijmeh said. 

    On Sept. 13, JFrog will host its marquee event: swampUP. For those anticipating this year’s event, this is more than just a conference. The people heading to San Jose, California, are dedicated to advancing the DevSecOps landscape, and the event is designed to foster a holistic environment for collaboration and learning, Nijmeh said.

    “It really brings everyone together. Whether you’re a DevOps practitioner, security practitioner, as well as leaders and managers, all in one place,” Nijmeh said. 

    Image from swampUP 2022 courtesy of JFrog

    This year’s theme, “Ready for Next,” captures JFrog’s dedication to continuous growth, she added. Nijmeh explained that organizations are always evolving and transforming, and that they need a partner that can grow with them.

    Among the numerous topics that will be discussed at JFrog’s ninth swampUP event is security and DevSecOps, Nijmeh said, adding that “security is top of mind as always.” 

    Several keynote speakers will focus on security, including Bruce Schneier, a security guru and New York Times best-selling author of 14 books.  

    And although security will always be a hot topic, DevOps is expected to generate buzz as well. 

    “We have John Willis, who’s known as the godfather of DevOps. We’re also having folks from Riot Games, Fidelity, Netflix, CapitalOne and others representing their use cases on how they are addressing not just DevOps, but DevSecOps, in some cases,” Nijmeh said. 

    With a star-studded roster of speakers, expectations are sky-high. Furthermore, Nijmeh explained that the show has continued to evolve and has grown to be much more comprehensive. 

    “It’s not just about DevOps, it’s [also] about security. All the way from the left to the right. From development to deployment,” Nijmeh said. 

    For attendees, JFrog has placed focus on actionable insights, as it aims to provide information and tools that can actually be implemented within their organizations right away. SwampUP aims to provide attendees with practical know-how. Although the goal is to be ‘ready for next,’ it’s vital that practitioners and leaders understand what they can do today as well. 

    “Anything that we announce at swampUP will be available to our customers,” Nijmeh said. We’ll be sharing some partner announcements and some new innovations that no one has ever seen before.”

    Image from swampUP 2022 courtesy of JFrog

  • Does Platform Engineering Make DevOps & DevSecOps Irrelevant?

    Does Platform Engineering Make DevOps & DevSecOps Irrelevant?

    For those of us old enough to remember, the DevOps movement came onto the scene somewhere around 2007/2008. Its proponents railed against the traditional software model at the time, which called for the developers who wrote the code to be organizationally and functionally separate from those who deployed and supported the code. The reasoning behind the movement is that these siloed teams, concerned only with their own objectives, resulted in botched releases, significant delays, poor communication and, ultimately, unhappy customers. It took a few years to gain traction, but when Gartner got on board with the concept in 2011, adoption soared, and Agile development practices like automated build and test and continuous integration and delivery became the new norm.

    Security and Compliance Join the Mix

    Agile, DevOps and its promise of continuous integration and continuous delivery … well, delivered. Development and operations teams were finally on the same page, each able to see a current phase’s end goal, providing the flexibility to make changes and improvements along the way, speeding the delivery of quality software. Unfortunately, in these early years of DevOps success, security and compliance generally remained siloed. That silo resulted in security being an afterthought—stuck near the end of the application development life cycle. Consequently, security took the blame for release-delaying bottlenecks.

    The year 2014 was notable for an exponential increase in security breaches compared to the year before. According to an article in Security Week, 2014 marked the year that, for the first time, one billion records were compromised in more than 1,500 notable data breaches, an increase of 80% from 2013. Home Depot, JP Morgan Chase and eBay were among the many exposed to attackers. Given these and other high-profile breaches, it was time to re-evaluate development processes and give security and compliance a seat at the table.

    With research by Microsoft and others showing that 80% of security breaches were related to configuration errors, the concept of DevSecOps, putting security front and center in the Agile development process, ensures that assets are configured correctly in the first place, providing continuous compliance by running constant scans to identify configuration drift.

    This approach can be extended beyond the data center to any cloud to any edge, where even applications can be managed and checked against compliance and security standards. You can even extend a single DevSecOps compliance framework to cloud native assets including Kubernetes and public cloud services. 

    Today, it is safe to say that the term “DevOps” is likely losing its relevance, but “DevSecOps” is alive and well, as long as the organization embraces the cultural, people and process changes necessary for success. Tools and technology are essential to DevSecOps, as is adopting a culture that security is everyone’s responsibility. That culture requires instigating a security-first mindset among teams as well as implementing essential automated security testing tools.

    What About Platform Engineering?

    Platform engineering has recently captured interest and is now generating considerable buzz due to its focus on building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management. The platform is supported by layered services or tools, created and maintained by a dedicated product team, designed to support the needs of software developers by essentially stitching together components to create a frictionless developer experience.

    As Gartner says, “Platform engineering is an emerging technology approach that can accelerate the delivery of applications and the pace at which they produce business value.” In fact, Gartner expects “[t]hat by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery. Platform engineering will ultimately solve the central problem of cooperation between software developers and operators.”

    In that context, platform engineering certainly builds upon the Agile concepts of DevOps and DevSecOps. Looking deeper at DevOps/DevSecOps and platform engineering shows that they both share many characteristics, while they can also be combined in a way that provides greater benefits to organizations that think about them in tandem. It is easy to see the integral link between platform engineering and DevSecOps and the broader infrastructure management landscape. For example,

    • Developer Experience and Productivity – DevSecOps extends experience and productivity support beyond the developer to IT Ops, security and compliance.
    • Automation – Automating infrastructure configuration as well as compliance tasks using a policy-as-code approach is the lynchpin of DevSecOps. Platform engineering provides the opportunity to extend automation to the other parts of the development lifecycle.
    • Self-service – This is another common concept where platform engineering can build off of the automation and services-oriented approach that DevSecOps uses to not only enable developer self-service for code/test/deploy, but also to enable developers to be more proactive and effective in the security/compliance realm.
    • Accelerate Value – Accelerating value is the focus of any tech enabler, from platforms to tools and processes.

    From an Agile development approach supported by DevOps/DevSecOps and extending now to platform engineering, the end game is all about speeding delivery of high-impact applications with continuous updates that are highly resilient, reliable and secure. Given the synergies and the pressure on organizations to rapidly deliver applications while combatting cyberthreats, any platform engineering effort should ensure that DevOps/DevSecOps plays a central role.

    While the term DevOps and, to some extent, DevSecOps, sound a bit dated and irrelevant and could maybe use a new moniker, the evolving role they are certain to play as platform engineering gains a foothold are not to be underestimated. 

  • Driving DevOps Excellence: Implementing SLOs for Your DevOps Team

    Driving DevOps Excellence: Implementing SLOs for Your DevOps Team

    In today’s fast-paced world of software development, when continuous deployment and frequent releases are the norm, DevOps teams are essential to facilitating smooth communication between development and operations. In a blog post on LinkedIn, I talked about the importance of service level objectives (SLOs) for the testing team to improve the overall product quality. On top of that, let’s look at how adding SLOs to your DevOps team can improve productivity, dependability and client happiness.

    The Role of SLOs for DevOps Teams

    • Aligning DevOps Goals with Business Objectives:

    SLOs help DevOps teams coordinate their efforts with business objectives. The DevOps team can concentrate on delivering real business value by setting precise performance indicators, such as deployment success rates or infrastructure provisioning timeframes.

    • Promoting Collaboration and Accountability:

    By implementing SLOs, several stakeholders—including development, operations, quality assurance and business teams—are encouraged to work together. Over each stage of the software development life cycle, this shared responsibility promotes a sense of ownership and accountability.

    • Driving Reliability and Stability:

    SLOs play a key role in ensuring the stability and dependability of the system. You can be sure that your services consistently fulfill client expectations when your DevOps pipeline adheres to defined SLOs.

    • Proactive Issue Mitigation:

    Monitoring and alerting systems are used together with SLOs. The DevOps team could avoid service outages and downtime by aggressively identifying possible problems and resolving them before they become more serious by regularly monitoring important indicators.

    • Data-Driven Decision Making:

    Decision-making is driven by quantitative data. With the help of such indicators, the team is able to identify bottlenecks, prioritize improvements and streamline processes based on quick feedback.

    Now, let’s explore some key areas where DevOps teams can set SLOs to improve their performance:

    1. Continuous Integration (CI):
    SLO: “xx% of builds complete within Y minutes.”
    Measurement: Monitor build times and queue times regularly.
    Action: Optimize CI infrastructure and configurations to meet the SLO.

    2. Continuous Deployment (CD):
    SLO: “xx% of deployments are successful.”
    Measurement: Track deployment success rate.
    Action: Improve the deployment process to meet the SLO and reduce deployment failures.

    3. Infrastructure Management:
    SLO: “xx% of infrastructure is provisioned within Y minutes.”
    Measurement: Monitor infrastructure provisioning time.
    Action: Optimize infrastructure provisioning scripts to meet the SLO.

    4. Monitoring and Logging:
    SLO: “DevOps tools and system uptime should be at least xx%.”
    Measurement: Monitor the availability of the DevOps pipeline, deployment system and other tooling, including monitoring and logging systems.
    Action: Ensure high availability for DevOps tools and components.

    5. Artifact Management:
    SLO: “Artifact retrieval time should be less than x seconds on average.”
    Measurement: Monitor artifact retrieval time and availability.
    Action: Optimize artifact storage and distribution mechanisms.

    6. Testing and Quality Assurance:
    SLO: “Code must have at least xx% unit test coverage.”
    Measurement: Track test coverage regularly.
    Action: Encourage developers to write more tests.

    7. Security and Compliance:
    SLO: “xx% of compliance checks must pass.”
    Measurement: Monitor the results of compliance checks.
    Action: Ensure necessary security measures to meet the compliance SLO.

    8. Standardized Tools Selection:
    SLO: “xx% of teams must use the approved CI/CD tools stack.”
    Measurement: Track the percentage of teams using the approved tools stack.
    Action: Encourage teams to adopt standardized tools and provide necessary training and support.

    9. Training and Skill Development:
    SLO: “xx% of team members should undergo relevant DevOps training annually.”
    Measurement: Monitor training completion rates.
    Action: Provide training opportunities and resources to help team members enhance their skills.

    Initially, teams should baseline which percentage values to track by observing the current state. In the event they don’t have the bandwidth to baseline, start with any reasonable arbitrary number over a period of time, and it will be automatically refined.

    Implementing service-level objectives empowers DevOps teams to focus on delivering reliable and high-performing services that meet user expectations. By setting clear performance and reliability targets, teams can proactively identify and resolve issues, leading to improved collaboration, efficiency and overall user satisfaction.

    SLOs are not rigid constraints but are a means to drive continuous improvement and foster a culture of excellence within the DevOps ecosystem. As organizations strive to keep up with the ever-changing demands of the digital world, embracing SLOs is a crucial step toward achieving DevOps excellence and ensuring a competitive edge in the market.

  • The Differences Between DevOps, DevSecOps and SRE

    The Differences Between DevOps, DevSecOps and SRE

    DevOps, DevSecOps and SRE are all quickly gaining traction within the tech world due to their effectiveness and promise of reliability for companies. Each framework provides various levels of safety and scalability—DevOps is agile, DevSecOps prioritizes security above all else and SRE focuses on performance optimization. Together, these are changing how software gets deployed from conception to production. We’ll break down each one in detail.

    What is DevOps?

    DevOps is a set of practices that combines software development and IT operations, which aims to shorten the software development life cycle (SDLC).

    DevOps bridges the gap between those two areas by bringing together different people–developers, operators, testers and system engineers–who are responsible for different parts of the software delivery process, from planning to deployment into production environments.

    A core tenet of DevOps is to automate manual processes within each stage of the SDLC, eliminating much of the redundant work that used to take weeks or even months. This automation significantly drives down costs, as well as reduces problems posed by human error when running manual tasks.

    The following are some of the core tenets of DevOps:

    1. Collaboration
    2. Quality and reliability
    3. Automation
    4. Scalability
    5. Security

    What is DevSecOps?

    DevSecOps (or DevOps security) is an emerging field within the DevOps practice that focuses on strengthening software security within the development and operations process.

    These three distinct groups often have different priorities when it comes to building software applications. Developers are focused on speed-to-market objectives from their employers or clients, operations focus on reliability and scalability, while security teams prioritize safety from malicious actors or data breaches. At the same time, with DevSecOps, these goals become united under one umbrella: Build fast and reliable applications with built-in protection against attacks.

    DevSecOps focuses on implementing security as code—or automating many routine tasks involved with identity management, like user authentication and authorization. To ensure that security is properly integrated into your DevOps pipelines, below are some key DevSecOps practices:

    1. Automate security processes whenever possible
    2. Encourage continuous testing
    3. Prioritize remediation over detection
    4. Create a culture around secure coding principles

    What is SRE?

    SRE stands for site reliability engineering. The basic idea behind SRE practices is that software engineers should be responsible for both the development as well as the reliability of their product as a whole. This means having an understanding of not only how users will interact with the application or service but also how it interacts with other services in its operating environment, such as databases, firewalls, cloud environments, etc.

    To maintain uptime while meeting these requirements, SRE applies various techniques like automation and continuous deployment processes to ensure high availability.

    A key goal of site reliability engineering is service-level objectives (SLOs), which measure how consistently a service meets its goals over a given period of time—such as how often it’s available, how quickly it responds to requests made by users or customers—and establishing goals around those SLOs. Achieving objectives like these helps organizations build customer trust in their products and services since it ensures that they have stable and reliable day-to-day operations.

    Here are some of the most important SRE principles:
    1. Automation
    2. Proactive monitoring
    3. Fault tolerance
    4. Measurement and analysis
    5. Service-level objectives (SLOs)

    DevOps Vs. DevSecOps Vs. SRE

    The differences between DevOps, DevSecOps and SRE can be summed up in three main areas: Scope, roles and objectives.

    DevOps focuses on improving the speed of releasing software by automating processes and optimizing collaboration between development and operations teams. This helps organizations create a continuous delivery pipeline to quickly deploy code into production with minimal risk. As such, it is typically focused on development or operations activities and has become synonymous with agile methodologies such as continuous integration/continuous delivery (CI/CD).

    DevSecOps expands upon these concepts to include security considerations from the very beginning of a project’s life cycle instead of tacking them on after the fact. By shifting security left in the process–meaning bringing security earlier into the design phase–teams are able to reduce risk early on while achieving faster results overall through continuous feedback loops.

    As part of this shift left process, DevSecOps practitioners focus heavily on automating security compliance activities as part of their job function rather than waiting until after deployment has occurred.

    Meanwhile, SRE focuses more broadly on keeping the user experience consistent across various products an organization offers by responding to customer needs quickly while creating automation processes that allow common tasks to be repeated without manual intervention from engineers or developers.

    Then there is also platform engineering, which is a closely related yet distinct discipline with its own unique responsibilities. While both DevOps and platform engineering involve automation and working with the infrastructure that supports software development, there are some key differences between them.

    Platform engineering can be defined as a practice that involves developing a standardized platform on which all applications will run. Platform engineers build the underlying infrastructure to support applications, including servers, databases, virtualization layers and networking components using standardized toolsets. An important task for this field is designing an application’s architecture in such a way that allows it to scale easily with increased demand or usage levels. Additionally, they create self-service tools that enable developers on their team to quickly spin up new environments without requiring outside assistance.

    Wrapping Up

    In conclusion, while all three approaches have similar goals–ensuring reliability, speeding up the software delivery process and securing user data–they do so using different strategies:

    ● DevOps favors automation.
    ● DevSecOps puts focus on proactive security measures.
    ● SRE prioritizes optimization, reliability and scalability.

    Each one can contribute significantly when appropriately implemented into any organization’s workflow, depending upon its own specific needs.

  • Low-Hanging Fruit, 2023 Edition: Part One

    Low-Hanging Fruit, 2023 Edition: Part One

    We’ve been cranking it out, haven’t we? Generating cool new toys for the business, creating new infrastructure to host those new toys and trying our best to secure all this new stuff while maintaining both our sanity and our cadence. And we’re doing it. Kind of.

    One thing we’re naturally lagging behind on is security. While we don’t purposely shortchange security in our DevOps processes these days, it always takes a bit to figure out the best way to secure new technologies after they’re implemented. And we’re implementing a ton of new technologies. So our security staff (and increasingly, DevOps/SRE teams) is rushing to play catch-up. One area where this is screamingly apparent is APIs. We’re spewing them across the organization, often without cataloging or responsibility. This makes sense, as in many cases, the API is just an evolution of the function call. “I need a service, it is a good generic service, let me throw it up and we can use it from wherever the client ends up deployed,” type of thing. The problem is that leaves a ton of attack surface not truly protected. Because without cataloging or responsibility, there is no way for security to know about many of these APIs.

    API Scanning Technology

    That brings us to today’s topic. If you haven’t done so yet, it is past time to look at API scanning technology. It comes standalone and bundled with pretty much any API security product on the market and is increasingly bundled with other development security or even development tools. And the whole point is to get a list of APIs. Oh, most commercial implementations do something with that list–include it in static testing, drive it into WAFs, whatever—but just having the ability to inventory what is running on your network is reason enough to stop doing less important stuff and figure out what your exposure is. And the tools make it easy. They come in two flavors, and we should consider both.

    Static API Scanning

    The first type digs through source code and API specs to come up with the list of what is supposed to be running on the network. The big weakness of this method is that it only knows what it is told. This is static API scanning.

    Dynamic Scanning

    The second watches network traffic for API calls and then documents them, possibly even generating API specs for you. The big weakness of this method is that it only discovers what is being accessed on the network while it is watching traffic. Currently, unaccessed APIs are not caught, nor are ones on unreachable networks. Unsurprisingly, this is dynamic scanning.

    As usual, the two together are more powerful than apart. By implementing both technologies, an organization can work toward a hardcore comparison of what should be running on the network versus what is running on the network. This goes beyond detecting unreported APIs, it also means that zombie APIs or runtime drift can be discovered by comparing what is there to what should be there.

    If you’re not doing this, consider adding it to the toolbox. Setup is not onerous, and the reports are lists of APIs and parameters that can be reviewed at leisure. Some commercial products that offer these two functionalities take it quite a way beyond list generation, and if comparisons are made, work hard to understand just how much each toolset can do.

    And keep rocking it. We need more tools to lock down the new perimeter precisely because you and your team are tackling new technologies and platforms to better serve the business. We are increasingly seeing security tooling catch up with the broad selection now available, so go implement them.

  • Digital.ai Embraces Multiple AI Classes to Advance DevSecOps

    Digital.ai Embraces Multiple AI Classes to Advance DevSecOps

    Digital.ai has committed to adding generative artificial intelligence (AI) and additional machine learning capabilities to its namesake platform for managing DevSecOps workflows.

    The company plans to make available in alpha a generative AI tool to create test cases and user stories via large language model (LLMs) access via a natural language interface. In addition, generative AI will also be used to identify high-risk changes to code and improve the overall governance of DevSecOps workflows.

    At the same time, Digital.ai has extended the machine learning algorithms it already provides to provide predictions and scoring. Additional capabilities include flow acceleration recommendations, change risk predictions and service management process optimizations.

    Digital.ai CEO Derek Holt said as AI continues to evolve, the company will use a mix of public and private LLM platforms to ingest AI into DevSecOps workflows. In effect, the future of AI will almost be multimodal as different classes of AI technologies are used to automate workflows, he added.

    The goal is to safely break down the silos of data that today make it difficult to cost-effectively build and deploy secure software without compromising the rate at which it is developed, noted Holt.

    It’s still early days as far as the infusion of AI in workflows is concerned, but it’s apparent that many of the manual tasks that prevent organizations from fully embracing best DevSecOps practices will be automated.

    At the same time, increased reliance on digital processes, coupled with more stringent pending regulations, are reducing the overall tolerance organizations have for insecure software. The only way to address that rising sense of application security urgency—at a time when more complex cloud-native applications are being built and deployed—is to rely more on automation. In fact, the race is now on to secure software supply chains before regulations that will have stiff penalties for security lapses go into effect.

    Most of the AI advances in software development that have been made thus far benefit developers. However, many of those same core AI advances will soon be applied to software engineering. Many of the DevSecOps bottlenecks that exist today will start to fade away as various classes of algorithms are able to both identify and make recommendations to eliminate them. As those capabilities evolve, it should also serve to help reduce the long-standing cultural divide between application development teams and cybersecurity professionals that is at the root of the software supply chain issues that organizations are still struggling to resolve.

    In fact, many organizations would be well-advised to review their current workflows with an eye toward determining which processes can be automated. The days when AI was sparingly used are now giving way to a new era of software development that promises to dramatically accelerate the rate at which applications can be built, deployed and updated. The challenge, as always, is finding a way to incorporate these advances into workflows that were not created with AI in mind.

  • Extending the GitOps Pipeline: DevSecOps and Trusted Application Delivery

    Extending the GitOps Pipeline: DevSecOps and Trusted Application Delivery

    We live in a fast-paced world of rapid changes and uncertainty where every aspect of our daily lives changes often, including the way we work and communicate. Organizations must deliver value to their customers at a much faster pace than ever before to thrive in such an environment. However, the decentralized nature of cloud infrastructure expands the threat landscape and poses several security risks that enterprises should address in light of recent data breaches.

    Organizations must combat security threats and address challenges arising from cloud misconfigurations. Several recent tools, strategies, practices and technologies have emerged that can help you handle such security threats. This article discusses how the fusion of DevSecOps and trusted application delivery can extend the GitOps pipeline and add business value.

    What is GitOps?

    Coined by Weaveworks in 2017, GitOps thrives on a source code management system built on Git and adheres to the belief that Git is the single and definitive source of truth. Since all changes are stored in Git, anyone can see the audit trail if necessary. This enables you to use Git-based version control to manage your application’s code, environment and processes.

    Figure 1: CI/CD with Git-based Version Control

    GitOps leverages Git repositories as the one and only source of truth and embraces DevOps and infrastructure-as-code (IaC) best practices. Using GitOps, your developers can spend more time developing applications than configuring or maintaining Kubernetes clusters.

    GitOps strategies are gaining traction with enterprises for various reasons, including improved productivity, increased deployment frequency and improved security. While it’s true that GitOps continues to be a transformative trend, the increased speed and automation can also lead to misconfigurations that compromise application stability and security.

    Figure 2: CI/CD using GitOps

    Often, these security vulnerabilities delay development as developers spend significant time and effort investigating them. Since this poses a hindrance to progress, the question that arises is how enterprises can maintain the frequency and speed of deployment while remaining secure and reliable. This is where trusted delivery comes in.

    An Extension of DevOps

    DevOps is a software engineering practice and culture that blends development and operations to provide a shared and collaborative approach to developing and maintaining software. This can boost productivity, lower costs and increase customer value through increased collaboration.

    GitOps extends DevOps to bring the deployment workflow closer to developers. GitOps integrates code and configuration management for cloud-native application deployment and administration, while DevOps fosters shared ownership, transparency, and rapid feedback.

    GitOps uses DevOps-proven practices like version control, code review and CI/CD pipelines with any Git-based repository, including GitHub, GitLab or BitBucket. It builds on DevOps and applies DevOps best practices for infrastructure automation.

    What is Policy-as-Code?

    When deploying and managing cloud-native infrastructures, adhering to security best practices and regulatory standards is critical without hindering development. Policy-as-code is an approach to infrastructure security in which rules are codified and enforced, thereby reducing or eliminating human errors. You can use it to write applications using a high-level language to control, manage and automate policies. With policy-as-code in place, developers may create applications to manage security, compliance and other regulations seamlessly.

    Here are the types of policies that you can codify:

    • Security Policies: By adhering to these policies, you can protect your software from data breaches caused by misconfigurations.
    • Resilience Policies: The use of these policies in your Kubernetes clusters will help you create highly available, fault-tolerant systems as well as maintain business continuity.
    • Coding Standards Policies: These policies can enforce coding consistency, i.e., any code that violates these policies will be rejected automatically by the system.

    What is Trusted Application Delivery?

    Trusted delivery entails codifying security policies within your software delivery pipeline for security and compliance and introducing guardrails at every stage. By ensuring the security, integrity and reliability of your applications deployed in production environments, unauthorized access, tampering or malware introduction is minimized. It establishes and maintains trust in application source code, artifacts and deployment pipelines throughout the SDLC process.

    The key objectives of trusted application delivery are:

    • Security: It protects the application from security threats and vulnerabilities
    • Integrity: It verifies the authenticity and integrity of the source code of your application, together with the dependencies, and any artifacts
    • Reliability: It ensures that the applications deployed to the production are stable and are devoid of any security loopholes so that they can perform as desired

    Trusted application delivery helps development teams release applications early and secures them with automated protections or guardrails. It extends the GitOps pipeline by integrating security, governance and verification with policy-as-code. These security measures are implemented with policy-as-code. The policy-as-code approach encompasses the entire SDLC, including the design, development, testing and deployment stages.

    According to your organization’s security and compliance policies, compliance and security rules are codified and integrated into the system. Throughout the life cycle of your application, you can manage its security, compliance and other regulations using policy-as-code. These code-defined policies prohibit the provisioning of non-compliant resources. You should implement trusted application delivery practices to secure your organization’s application delivery process and reduce the likelihood of unauthorized access.

    Here are the key benefits of trusted delivery:

    • Faster and more frequent releases
    • Enhanced security
    • Protect against misconfigurations
    • Avoid compliance violations
    • Improved collaboration

    What is DevSecOps?

    DevSecOps is a software development methodology that blends development (Dev), security (Sec) and operations (Ops) at all phases of the SDLC by incorporating mandatory security checks. An organization of any size can benefit by creating a culture of shared responsibility and collaboration by bridging the gap between development, security and operations teams.

    A DevSecOps pipeline adds practices such as scanning, policy enforcement, static code analysis, threat intelligence and compliance validation to the SDLC process. Contrary to traditional software development processes that treat security as an afterthought leading to security vulnerabilities and breaches, DevSecOps is a paradigm shift that fosters a culture of proactive and continuous security approach to help address security concerns and vulnerabilities.

    DevSecOps and GitOps help organizations adapt quickly to changing emerging trends and requirements. DevSecOps is an offshoot of DevOps that focuses primarily on security throughout the development process. It helps detect and resolve security issues and vulnerabilities easily and quickly while fostering a culture of continuous improvement.

    Here are the benefits of DevSecOps at a glance:

    • At the outset, determine which points in the SDLC process are susceptible to security flaws and vulnerabilities in the SDLC process
    • Streamlined compliance
    • Secure supply chain
    • Reduced risk of the attack surface
    • Complete visibility of potential threats

    Why DevSecOps?

    DevSecOps is a proven way to secure your CI/CD pipelines, deliver secure, trusted, high-quality software and foster an environment where security is the responsibility of everyone in the organization. By shifting security left—i.e., introducing security into the CI/CD pipeline earlier—organizations can be much more productive and the teams can be more cooperative and collaborative.

    Given the threats to the security of the software supply chain, DevOps practices have given way to DevSecOps practices, where safety is paramount and a fundamental and ongoing component of software development. At the outset of the SDLC, you should ensure that software components and dependencies are secure to avoid potential software supply chain hazards.

    Additionally, it would help if you had built-in security gates in each step of the SDLC to ensure consistent, repeatable and automated processes from the software build phase to deployment. Remember, DevSecOps isn’t an option; instead, it is a necessity.

    Trusted Delivery With GitOps

    Automated software delivery pipelines are based on Git as the only source of truth. Policy-as-code is a great way to ensure that misconfigurations and errors are detected, alerted, and deployments halted automatically. Next, we’ll cover how a typical GitOps workflow determines where multiple checkpoints can be implemented for trusted delivery.

    In a typical workflow based on GitOps, a developer commits the source code to a Git repository. The CI tool then builds the container images. These container images are then tested and then uploaded to an image repository. At the end of this process, these container images will be deployed to a Kubernetes cluster. GitOps agents compare the current cluster state with the desired state on a continuous basis.

    Hence, you should implement security guardrails at the following points:

    • Git repository
    • CI stage
    • Configuration repository
    • Kubernetes cluster

    Creating a Trusted Software Supply Chain With DevSecOps

    You can build a trusted software supply chain by incorporating security practices throughout the SDLC to ensure the integrity and security of the software delivered by DevSecOps. Here is a step-by-step guide to building a trusted software supply chain by leveraging DevSecOps principles:

    • Security by Design: You should integrate security right from the outset of the SDLC and identify the key threats to the security of the pipeline.
    • Application Dependency Scanning: When building applications, we often use third-party dependencies to accelerate the development process. You should monitor security vulnerabilities and patches as they become available for these dependencies. You can leverage OWASP Dependency Check, Firewall from Sonatype, etc.
    • Secure Coding Practices: You should adhere to and enforce these practices among your development teams. You can integrate static code analysis tools into your DevSecOps pipeline, conduct regular code reviews and identify and fix security issues.
    • Container Security: You should scan container images regularly for security vulnerabilities, implement strategies to secure your containers and use container registries with access controls.
    • Continuous Compliance: You should ensure the software supply chain adheres to the relevant standards and guidelines for compliance requirements. In this regard, you should conduct audits regularly to check if compliance requirements have been satisfied.
    • Collaboration and Communication: You should be able to foster a culture in your organization that facilitates collaboration and communication across the development, operations and security teams.

    DevOps, DevSecOps and GitOps: The Future

    As organizations strive to optimize the efficiency of their software supply chain, DevOps, DevSecOps and GitOps are approaches that can improve collaboration, efficiency and security, to help software developers and IT operations succeed. These practices would become more critical and widely used in the future. GitOps provides teams with better tools for managing configurations so they can focus on more strategic activities.

    While GitOps is an approach that advocates Git-based version control systems as the single source of truth, DevOps is concerned about a cross-functional team that can work together. DevSecOps goes a step further by blending security into all stages of the SDLC process.

    The future of DevOps, DevSecOps and GitOps will see increased automation, tighter security integration and a sustained emphasis on efficiency and collaboration. Your organization should adopt these approaches to provide reliable software and services to its customers.

    Conclusion

    Trusted application delivery is essential for securing applications, protecting user data, meeting compliance requirements and preserving market credibility and trust. It helps enterprises and end consumers by ensuring that software is distributed securely and reliably. Organizations can ship high-quality applications with guaranteed security and performance by adopting trusted delivery practices.

  • Communicating Common Web App Security Threats to Developers

    Communicating Common Web App Security Threats to Developers

    Automated security testing tools enable us to identify web application vulnerabilities early and often, but what happens after a vulnerability has been identified? Does your security team have the coding skills to mitigate it themselves, or are your developers suddenly security experts once a vulnerability is discovered? Most likely not. So, how do we go from finding vulnerabilities to fixing them? Enter a key component of shifting left: Collaboration between security and developer teams. And a portion of that involves providing developers with the context they need to prioritize and remediate threats appropriately.

    Useful context includes (but is not limited to):
    – The vulnerability type
    – How it works
    – What malicious actors can accomplish by exploiting the vulnerability
    – Ways to mitigate

    The list below provides context around five common web application security threats to help you collaborate on resolutions with your developers. A shared understanding of these threats and how to mitigate them early in the development life cycle will significantly improve overall security posture without impacting software delivery.

    SQL Injection

    A SQL injection attack is executed when an attacker injects malicious code into an application’s database through user-controlled data. While these types of attacks can accomplish many different things, there are several common outcomes. SQL injection attacks can enable attackers to gain unauthorized access to sensitive data stored in the database, and largely depending on what data is stored in a particular database, can result in access to authentication information, financial information and personal data. The second key outcome is the manipulation or removal of data. Malicious actors can then leverage this outcome to access the larger infrastructure and find even more sensitive information.

    To help protect against SQL injection attacks, organizations should never implicitly trust and always validate user input and utilize input encoding, prepared statements, parameterized queries or stored procedures instead of dynamic SQL statements whenever possible. By combining frontend and backend standards to prevent SQL injection from happening, your application can increase its security against this type of threat.

    Cross-Site Scripting (XSS)

    Another common web application attack is cross-site scripting (XSS) which involves inserting malicious code or script into a website. The website will then execute on the given script, enabling attackers to steal sensitive user data, such as session tokens and cookies.

    There are three main types of XSS attacks we regularly encounter: Reflective, stored and DOM. Reflective XSS attacks insert malicious code into a website that is immediately executed, whereas a stored XSS attack involves injecting malicious code into a website that is stored and executed later. DOM XSS is an attack pattern that is used more in single-page applications but acts similarly to reflective XSS. If successful, a cross-site scripting attack can lead to the theft of user session IDs and/or website defacement and lead to redirection to malicious sites, thus enabling phishing attacks.

    Similar to SQL injection attacks, to protect against cross-site scripting, organizations must never implicitly trust and always validate user input and use output encoding techniques while also using auto-sanitization libraries such as OWASP AntiSamy and implementing a content security policy.

    Cross-Site Request Forgery (CSRF)

    Cross-site request forgery (CSRF|XSRF) attacks trick users into performing an action on a website without their knowledge or consent. This is often achieved by inserting a malicious link or form into a website where a user is already authenticated. When the user clicks the link or submits the form, the action is performed on their behalf, leading to potential data loss or unauthorized access.

    Mitigating these types of attacks requires leveraging CSRF protections which are built into the framework you are using, if applicable. Using CSRF tokens, which are unique, randomized values associated with a user’s session and can verify the authenticity of a request will also help migrate an attack. In addition, SameSite cookie settings can help prevent attackers from being able to send requests on behalf of a victim.

    Insecure Direct Object References (IDOR)

    Insecure direct object references (IDOR) occur when an application exposes direct object references, like URLs or database keys, which allow attackers to gain access to restricted data by manipulating these references.

    Safeguarding against IDOR requires the implementation of proper access controls and session management, ensuring that only authorized users have access to certain resources or data. Also, avoid using predictable references and instead utilize globally unique identifiers (GUIDs) to prevent attackers from guessing the direct object references they need to access restricted data.

    It is important to remember that IDOR-based vulnerabilities don’t occur singularly and are coupled with other vulnerabilities to become an effective attack vector.

    Remote Code Execution (RCE)

    Remote code execution (RCE) gives an attacker the ability to execute arbitrary code on a server, which can lead to the compromise of entire systems and offer unauthorized access to highly sensitive data. RCE attacks can occur through an array of means, including exploiting vulnerabilities in code libraries or injecting malicious code through user input fields. As illustrated by the critical zero-day exploit discovered in the Java logging library Log4j in December 2021, RCE can be a determinantal vulnerability.

    A successful RCE attack can cause denial-of-service (DoS) attacks, expose sensitive data, lead to illicit cryptocurrency mining and the execution of malware. In more severe instances, a successful RCE attack can allow an attacker to gain full control over the compromised machine.

    The good news is organizations can implement the same tactics used for protection against SQL Injection and XSS—never implicitly trust user data and adhere to strong user input sanitization and validation.

    Understanding Common Threats

    Safeguarding applications and ensuring a sound security posture requires both security and developer teams to have a shared understanding of common threats and the associated risks.

    The details provided in these examples only scratch the surface in terms of useful context for developers. When you can pinpoint when a vulnerability was introduced, which repository branch and code commit it’s associated with and whether it is exploitable from the outside, you create a powerful feedback loop that accelerates fixes.

  • How to Empower DevSecOps in a Complex Multi-Cloud Landscape

    How to Empower DevSecOps in a Complex Multi-Cloud Landscape

    Organizations are embracing cloud-based application delivery for speed of delivery and scale. However, the proliferation of multi-cloud systems to access and maximize the cloud’s capabilities is driving complexity in IT environments. Many organizations do not consider how multi-cloud adoption is expanding their attack surface—and the risk is growing: The 2023 CrowdStrike Global Threat Report found cloud exploitation cases grew by 95% year-over-year and cases involving threat actors targeting cloud environments were up 288% from a year prior.

    The expansion of cloud infrastructure and services has increased the pressure on organizations to protect assets within their multi-cloud environments. To alleviate this burden, more businesses are turning to DevSecOps, a practice that incorporates security at an earlier point in the development life cycle. This practice of shifting left helps improve the quality and reduces risk of applications, as well as makes the delivery of these applications more efficient since any potential issues are found earlier in the development process.

    DevSecOps is being adopted rapidly by organizations today to address the expanding array of threats and increasingly sophisticated attacks targeting multi-cloud environments. However, securing the cloud can be tricky due to its dynamic nature and multi-cloud makes shift left security even more complex. For DevSecOps to truly be effective, here are three things that organizations should consider doing.

    1. Strive for Complete Visibility in a Multi-Cloud Environment

    It is important that DevSecOps teams have a comprehensive understanding of their multi-cloud environment. Without it, they will not be able to identify a variety of security risks including vulnerabilities, privileged credentials, misconfigurations and other threats that may leave their organization’s cloud assets vulnerable.

    The best way to get full visibility across multi-cloud environments is through a cloud security posture management (CSPM) tool. With a CSPM tool, DevSecOps teams can identify misconfigurations and proactively detect threats. In addition, DevSecOps teams should also use a cloud infrastructure entitlement management tool (CIEM) to manage identities across all of their cloud infrastructure resources. The primary goal of a CIEM tool is to mitigate the risk that comes from the unintentional and unchecked granting of excessive permissions of user credentials.

    2. Visibility and Compliance Do Not Guarantee Security

    Organizations need to develop a comprehensive security strategy to mitigate issues within the development process. This may include implementing tools, automation and standards to enable developers to follow the desired security behavior. These approaches reduce developer friction, as well as diminish the likelihood that unsafe or default configurations will be used. Historically, DevOps teams have pushed back on integrating security since their concern is that it slows down the development lifecycle. However, DevSecOps is gaining traction in recent years because organizations are realizing integrating security sooner in the development lifecycle is more efficient than reactively patching problems as they arise.

    A tool that DevSecOps teams should look to leverage is cloud workload protection (CWP) because it offers breach protection for workloads, containers and Kubernetes, while enabling them to continue to build, run and secure applications with speed and confidence.

    3. Create Consistency With Security Tools

    Ideally, organizations should opt for a single platform that consolidates capabilities such as CSPM, CWP and CIEM. The reason for consolidation is to eliminate security gaps from having multiple security solutions. As a result, DevSecOps teams should turn to cloud-native application protection platform (CNAPP) tools to create more consistency within the multi-cloud environment.

    Securing multi-cloud environments can be complex. By empowering DevSecOps teams using these best practices, organizations will be able to move faster than today’s adversaries and have the agility to quickly adapt to present and future cybersecurity challenges in their multi-cloud environments.

  • The Security Pipeline

    The Security Pipeline

    Over the last few years, the ability to secure our applications has grown, and deep integration into the DevOps toolchain has, too. There are more tools doing more security checks protecting more of the infrastructure and source than there have ever been. The key is putting them to use intelligently.

    We now have the ability to secure the image an app is based upon, the images that are derived from that original—complete with supporting software. We can get feeds to tell us which bits of our included open source components are insecure and how to protect them; we can scan the source, the assembled application, the APIs and the network. We can put runtime protections in place in front of web apps and in front of APIs. We can even track the long-tail attacks like slow data extraction that are becoming more common as security tools master more obvious attacks.

    That is a great set of security capabilities. And automation puts every bit of it within reach. Your job is to pick the bits you need to increase the security posture of your environment and get them worked into your specific toolchain. This is not all that difficult, but nothing is free, so you will need at least some implementation time and some staff time to work through results. After all, no matter how automated, current solutions do end with a list of changes that need to be made to increase security. Some tools will put a runtime fix in place immediately, but honestly, that is a patch—it only stays in place until you can fix the underlying issue.

    Integrating all of the great security tooling with each other is another aspect that will require some time. Some vendors cover a massive amount of the security testing needed across markets and technologies. These companies show us that even if an organization would rather use best-of-breed, there is a lot of benefit in increasing integrations. For an easy example, consider this: If the software bill of materials (SBOM) generated during the build steps shows that a given framework is included in an application, then active testing via dynamic or interactive application security testing can include extra tests specific to that library.

    Integrations will take effort, but once they’re in place they will enhance application security. There is no perfectly secure application, but the tooling is available to make a given environment less of a target because it is too much work to attack. And that is what you should be shooting for.

    I’ve said before that making security part and parcel of your DevOps practices is mandatory at this point, but that was in reference to the great DevSecOps toolsets currently out there. I’m suggesting now that we include it all–from design to GitOps runtime drift management. Because we can, and the result is reduced risk to the organization.

    And keep rocking it. Honestly, you’re maintaining something worth protecting–that alone means you are successful, even if you aren’t aware of every issue that crops up. Issues are why you’re there, and the systems keep running because you are.