Skip to content

staging-devopsy.kinsta.cloud

Latest
Topics
Videos/Podcasts
Webinars
Library
Events
- Upcoming Events
- On-Demand Events
Sponsored Content
Related Sites
Media Kit
About
Sponsor
SEARCH BOX

Tag: devsecops

Is SASE the DevSecOps of Infrastructure Management?

DevOps gained traction when IT and Ops (operations) teams recognized that traditional silos and handoffs were leading to inefficiencies and delays in software delivery. While DevOps enabled seamless collaboration and delivered on its promise of speed and efficiency, security remained an afterthought. To overcome the security loophole, DevSecOps emerged, proposing a shift-left approach to security. It emphasizes conducting tasks like security scanning, vulnerability assessment, and compliance checks all throughout the CI/CD pipeline.

With DevSecOps, speed no longer comes at the cost of security.

The DevSecOps approach has helped organizations strike the right balance between security and agility in software development. As the infrastructure landscape continues to evolve with the rise of cloud and edge computing, resource-intensive AI and ML initiatives, and distributed workforces, organizations must establish a similar balance between security and ubiquitous connectivity. This is where secure access service edge (SASE) comes in.

SASE’s Philosophy is Similar to DevSecOps

As legacy networks — characterized by rigid hardware-based infrastructure — struggled to keep pace with the demands of modern business, SD-WAN emerged as a solution, providing flexibility, centralized management and dynamic traffic routing. However, when distributed computing and remote work virtually dissolved the corporate perimeter, perimeter-focused security tools were no longer sufficient either. Today, enterprises must extend their security capabilities to almost unlimited network access points.

SASE addresses this challenge by merging networking and security into a single cloud-native framework. It integrates the entire security stack across all edge locations, ensuring secure connectivity between users, applications and resources no matter where they are. Just as DevSecOps shifts security to the left, making it an inherent part of the entire SDLC (software development lifecycle), SASE shifts security to the network edge, making it an inherent part of network connectivity.

The strategic resemblance between the philosophy behind SASE and DevSecOps is uncanny.

1. Breaking Silos

DevSecOps breaks down the silos between DevOps and security teams, promoting collaboration and shared responsibility. In a similar vein, SASE unifies all network and security functions into a single architecture, effectively dismantling the conventional boundaries between the networking and security teams. It allows both teams to jointly manage, monitor, and secure the infrastructure and network traffic through a unified management dashboard. SASE also effectively breaks the data silos that leave security teams with no insights regarding the networking conditions. SASE’s single pane of glass visibility enables networking and security data correlation, broadening each team’s perspective and eliminating tunnel vision for accurate and robust threat detection and an enhanced security posture.

2. Embracing the Cloud

DevSecOps aligns perfectly with cloud-native technologies like infrastructure as code (IaC) and containerization technologies like Docker, making it imperative for cloud-first and cloud-ready organizations. On the other hand, SASE is inherently cloud-native. It delivers network and security services from the cloud, providing organizations with the agility and scalability needed to meet the dynamic demands of a distributed environment.

Traditional back-haul-based connectivity and perimeter-based security solutions introduce latency and coverage gaps. SASE performs network and security functions at the edge, closest to wherever resources and users are. This eliminates the need for disparate on-premises point solutions and extends corporate security perimeter to match the cloud’s global reach.

3. Agility Through Automation

DevSecOps emphasizes automation of security tasks, such as security checks, scans and compliance assessments, within its continuous integration and continuous delivery (CI/CD) pipelines. SASE also leverages automation for networking and security tasks, such as dynamic policy enforcement, AI-driven threat detection and response, and network optimization through dynamic routing and self-healing properties. Automation reduces the need for manual intervention, bolsters security, simplifies operational tasks and enables organizations to respond to evolving demands and circumstances faster, crucial for agile environments.

SASE as an Enabler for DevSecOps

Just as DevSecOps enhances security within the context of application development, SASE enhances security and efficiency within the realm of networking and infrastructure management. Both approaches share the common goals of integrating security, promoting automation and ensuring scalability. They may apply these principles to different aspects of IT and cybersecurity, but DevSecOps and SASE can work together seamlessly to support modern IT environments.

Many organizations adopting DevSecOps realize that they lack the necessary infrastructure to support this approach effectively. DevSecOps demands seamless global collaboration and the integration of security controls across the entire IT environment. This is something SASE can help with. It can simplify infrastructure management and enhance security for DevSecOps in several ways. It offers ubiquitous connectivity for seamless collaboration, provides built-in security measures for faster incident response and ensures reliable infrastructure. As such, these are all crucial aspects for achieving the ultimate DevSecOps goal of delivering secure and high-performance applications at speed. With SASE, organizations can set their DevSecOps up for success.

November 30, 2023
CISA, NSA Issue Supply Chain Security Guidance Report

The National Security Agency (NSA), Office of the Director of National Intelligence (ODNI) and Cybersecurity and Infrastructure Security Agency (CISA) have issued guidance to assist software developers and suppliers to shore up software integrity and security across various stages of the software lifecycle.

The report, Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption, was developed by the Enduring Security Framework (ESF) Software Supply Chain Working Group.

The report offered recommended practices as a framework for assessing and improving security practices concerning software development, release, updates, vulnerability notifications and mitigation.

The guidance also addressed the escalating cybersecurity threats targeting software supply chains, which have exposed vulnerabilities susceptible to exploitation by state adversaries.

It highlighted potential risks such as design flaws, integration of vulnerable third-party components, infiltration of supplier networks with malicious code and malware injections in deployed software.

To combat these threats, the report underscored industry best practices, emphasizing open source software management and software bills of materials (SBOM).

Specific areas covered include SBOM consumption, life cycle, risk assessment and operational implementation, ultimately promoting enhanced transparency and risk management throughout software life cycles for organizations.

Alex Kreilein, vice president of product security at Qualys, said while the concept of an SBOM is not new, organizations now have concrete and foundationally important guidance on how to make operational use of SBOMs while developing, managing or consuming them.

“The guidance supplied by the Enduring Security Framework reduces the complexity of SBOM management, making it accessible to everyone for the first time,” he noted. “SBOMs are part of a healthy software ecosystem, but are by no means the only factor.”

He explained that while the SBOM is an effective output, it cannot be trustworthy if the system that created it cannot validate the provenance of the product.

“It’s critical for organizations to understand the whole supply chain from code through pipeline to production,” Kreilein said.

He added that this is why The Linux Foundation and Google started the Supply-chain Levels for Software Artifacts, or SLSA framework, as a practical set of methods to action NIST recommendations in the Secure Software Development Framework (SSDF).

John Gallagher, vice president of Viakoo Labs at Viakoo, called the report a “major step forward” in providing an overall framework and transparency for how SBOMs are constructed, maintained and used.

“One of the key ways this helps relieve concerns over software supply chain security is by providing clear guidance on the risk scoring mechanisms,” he said.

This augments other software supply chain efforts (though it doesn’t replace them) in areas like the use of SBOMs in SaaS environments or version control mechanisms for SBOMs.

He noted two significant points on implementation that come out of this framework; first is that it gives guidance to departments like procurement as to what they should be requiring from their vendors, and second it gives a framework for solution providers to base their consumption and generation of SBOM and Vulnerability-Exploitability eXchange (VEX) data on.

“While this document does not address the methods of remediation, it does help to more quickly identify software supply chain vulnerabilities so that they can be addressed early on and ideally before the widespread use of that vulnerable code,” Gallagher said.

He noted that the more vulnerabilities that are caught early or before they are broadly used the later stage of remediation is either much easier or not needed.

Anthony Tam, manager of security engineering at Tigera, said when vulnerabilities have been identified, it is important to prioritize them based on severity and potential impact.

“This allows organizations to allocate their resources more effectively and focus on the most critical vulnerabilities first,” he explained.

Prioritization can be done by using a risk-based approach, considering factors such as the likelihood and potential impact of a vulnerability being exploited.

“By prioritizing vulnerabilities, organizations can ensure that they are addressing the most critical security risks first and reducing the overall risk to their software system,” Tam noted.

November 21, 2023
Where to Start With Secure Design – Tips for Developers

Designing secure software is an increasingly hot topic, and for good reason. In recent weeks, we’ve seen a global effort from governments and cybersecurity agencies to encourage security by design through new guidance and changes to procurement rules. During the G7 in May, the QUAD nations (Australia, India, Japan and the United States) released a set of Joint Principles for Secure Software. In the U.S., there are even plans for legislation to make software makers liable for the security of their products. The need for software to be made secure at the design phase has been spotlighted further by recent cybersecurity incidents such as the hack by ransomware group CLOP that exploited flaws in MOVEit software.

But secure design is not a part of every developer’s skill set, and it’s not on the syllabus of every coding course. If you’re brilliant at writing code and keen to know more about how you make that code secure, where do you start?

Here are five tips from former DevSecOps and threat modeling engineer Fraser Scott, now IriusRisk’s VP of product:

1. Get to Know the Threats

To be able to design secure software effectively, you need to understand the threats. A great starting point is the OWASP Top 10. OWASP aims to identify the most critical security risks to web applications. Top of that list is broken access control, and insecure design itself sits at number four. Understanding the biggest risks is the first step towards mitigating them in software development.

2. Try Threat Modeling

The foundation of secure design is threat modeling, which is the process of identifying and mitigating plausible security threats. In its simplest form, this is about looking at your software design and asking Adam Shostack’s four questions:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

The OWASP Top 10 gives you a sense of what the risks might be, and threat modeling is the process of identifying them in your design. See if any of those top ten risks might impact your design, consider what could go wrong and work out what you can do to mitigate it. Before you start writing any code, consider whether you’ve done a good enough job to make the software secure. The sooner you find design issues, the cheaper and easier they are to fix.

3. Connect With a Community

There are plenty of communities of people out there grappling with the same challenges that you are. Experts in security and threat modeling and developers are coming together to discuss and try to solve some of the key challenges in secure design. One such community is Threat Modeling Connect, where people use the forum to share ideas and discuss issues. Experts also host webinars and write blogs. The community also held its first-ever conference in October. There is also a community dedicated to threat modeling on Reddit, and the OWASP Slack has a #threat-modeling channel.

4. Experiment With Automation

Companies who are developing software on a large scale use tools to automate the threat modeling process. IriusRisk makes a community edition of its automation tool available for free, for life, to people who want to give threat modeling a try. As someone who is starting out in secure design, using a tool like this, which generates many of the relevant threats and countermeasures for you, is a great way to experiment with your first threat models. And we’re not the only ones; you can also use the OWASP Threat Dragon and Microsoft’s Threat Modeling for free.

5. Build a Library of Secure Code

One shortcut to secure design is using existing secure design patterns and road-tested components. As you develop software, keep a library of secure code that has been threat-modeled and scanned using application security testing tools that you can return to in the future. The Threat Model Cookbook on Git Hub has some sample threat models you can use as a starting point.

November 17, 2023
Elastic Previews Unified Query Language for Search Platform

Elastic this week previewed a standard query language that can be used across its portfolio to streamline investigations into IT and cybersecurity events.

Gagan Singh, vice president of product marking for Elastic, said Elasticsearch Query Language (ES|QL) makes it simpler, via a single query, to aggregate data from multiple sources using a piped query syntax that makes it simpler to iteratively interrogate data.

Scheduled to become generally available in 2024, ES|QL replaces the multiple domain-specific languages the company has been providing for each version of its search engine. Instead of having to move data into a central repository, Elastic Seach makes it possible to query data wherever it resides in an organization, noted Singh.

That approach enables, for example, a site reliability engineer (SRE) to discover the root cause of an issue through a series of queries that can be launched from a familiar search interface, he said. It will also foster increased collaboration across IT teams that need to visualize query results, added Singh.

In general, IT teams are struggling with an exponential increase in the amount of data they need to analyze to discover the root chaise of an issue, noted Singh. The Elastic search engine provides a means to analyze that data at the level of scale that is now required, he added.

The preview of ES|QL comes on the heels of a technical preview of a generative artificial intelligence (AI) tool for observability the company has made available. The Elastic AI Assistant for Observability makes use of large language models (LLMs) and the Elasticsearch Relevance Engine (ESRE) to explain application errors, log messages, alerts and recommendations for improving code in plain language. DevOps teams can visualize and interactively chat with telemetry data and then invoke runbooks to remediate issues.

Elastic has also generally made available a Universal Profiling tool to enable DevOps teams to identify bottlenecks that adversely impact code performance.

There is little doubt that fundamental changes to how DevOps and cybersecurity teams interact with telemetry data are on the way. The challenge now will be determining when to rely on a generative AI tool versus diving deeper into that data by launching a series of queries. At the very least, AI should provide DevOps and cybersecurity professionals with a better sense of where to start an investigation.

Ultimately, the goal should be to reduce the level of DevOps and cybersecurity effort that is currently required to succeed. In theory, as it becomes simpler to investigate issues, the number of organizations capable of embracing DevOps best practices should increase as well. That’s crucial because IT environments are only becoming more complex with each passing day. The number of dependencies that exist between services has become too numerous for IT teams to track manually. More challenging still, those services are dynamically being updated, so what was known today about them might no longer be relevant tomorrow.

Hopefully, the amount of time and toil required to address issues will significantly decline in the months ahead as the next generation of tools becomes available. The challenge now is hanging on long enough for them to be battle-tested.

November 10, 2023
Survey Surfaces Software Supply Chain Security Challenges

A survey of 268 security leaders and 252 developers published this week found that while there is general agreement on the importance of software supply chain security, there is a significant disconnect on what is required to achieve that goal.

Conducted by the Harris Poll on behalf of Chainguard, a provider of curated container images for building secure software, the survey found 92% of developers acknowledged software supply chain security is at least very important, with 39% noting it as absolutely essential. Similarly, 96% said effective software security practices are important to meeting government or regulatory requirements, with 93% noting effective software security as a critical component of their threat and risk mitigation strategy.

Overall, most security leaders (70%) and CISOs viewed software supply chain security as a top priority. However, only slightly more than half of developers (52%) agreed. Nearly three-quarters of developers (72%) said they are very security-conscious, but only 50% of security leaders rated developers as very security-conscious.

Roughly two-thirds of security leaders (69%) and developers (64%) agreed that lack of communication and collaboration between developers and security teams is a problem. More than three-quarters of security leaders (77%) and more than two-thirds of developers (68%) agreed that the need to prioritize security causes tension between their teams. Nearly three-quarters of developers said the work/tools their security team requires them to use interferes with their productivity and innovation. Tools in place included software bills of materials (SBOMs) (40%), and nearly half are implementing software supply chain security frameworks such as Supply-chain Levels for Software Artifacts (SLSA) (47%) and the Secure Software Development Framework (47%) defined by the National Institute of Standards and Technology (NIST).

The report also found that 36% of security leaders and 34% of developers viewed an overwhelming number of scanner false-positive vulnerability alerts as being among the biggest software supply security obstacles an organization faces.

Most security leaders (74%) and developers (85%) believed that prioritization of software supply chain security would increase over the next five years.

However, many developers don’t believe enough security teams understand core software. Developers said security teams are generally familiar with open source software libraries and projects (61%), source code repositories and source code management systems (60%) and software build tools (59%), but only 43% said security teams are very familiar with container images.

On the plus side, many security leaders and developers understand that best practices and tooling in software security to drive certain business outcomes is essential, including customer retention (43% and 40%), meeting or satisfying procurement contract obligations (36% and 32%), fewer breaches or compromises (34% each), and developer/engineer productivity (32% and 34%).

Kim Lewandowski, chief product officer at Chainguard, said the survey makes it apparent that while progress toward securing software supply chains is being made, much work still needs to be done as silos between the developers and security leaders who are ultimately responsible for application security persist. While more organizations than ever have embraced DevSecOps best practices to achieve that goal, the cultural and technical challenges many organizations encounter are often underestimated, she noted.

The issue, as always, is that given the limited resources available, many organizations, despite their best efforts, are clearly still finding it difficult to stay current with updates to remediate vulnerabilities as they become available.

November 9, 2023
Transitioning Legacy Systems to DevOps: The XDR Support Paradigm

In today’s rapid and evolving technological landscape, DevOps emerges as a frontrunner in development methodologies, promising agility, efficiency and continuous delivery. While companies are keen to leverage its benefits, the transition from legacy systems can be fraught with challenges. Integrating extended detection and response (XDR) while making this transition can serve as a powerful tool to manage these challenges. In this article, we will delve deep into the potential pitfalls of this transition and explore the remedial measures with the aid of XDR solutions.

The Legacy System Quagmire

Legacy systems are often monolithic, siloed and heavily dependent on older technologies. According to a report by Forrester, a staggering 72% of corporate architectures still run on legacy systems. These systems, while operational, often lack the flexibility and scalability required for a DevOps-driven environment. They can become roadblocks, slowing down processes and becoming vulnerable points of failure.

The Inherent Challenges

Scalability Concerns: DevOps emphasizes scalability. However, legacy systems weren’t built with this level of dynamism in mind. Most legacy systems face scalability issues when introduced to DevOps practices.

Security Vulnerabilities: The older tech stacks are more vulnerable to modern-day threats. Without continuous updates, these systems become an attacker’s paradise. This is where XDR solutions come into play, offering real-time threat detection and response across the infrastructure.

Integration Hurdles: Legacy systems often struggle to integrate with modern tools used in DevOps, from container orchestration tools like Kubernetes to configuration management tools like Ansible.

XDR to the Rescue

Holistic Threat Detection: XDR’s primary strength lies in its comprehensive threat detection across networks, clouds, endpoints and applications. This compensates for the potential vulnerabilities of legacy systems, providing a safety net.

Real-time Responses: XDR doesn’t just detect threats; it actively responds to neutralize them. As per a study by IDC, integrating XDR can reduce incident response times by up to 50%, ensuring that any security breach on legacy components is swiftly managed.

Forensic Capabilities: Understanding the root cause of issues is paramount. XDR solutions come with forensic capabilities, allowing teams to understand the “how” and “why” behind incidents, an essential feature when dealing with older systems that may lack documentation.

Migrating With Minimal Friction

Training and Skill Development: One of the most underrated challenges is the lack of skills in managing and migrating legacy systems. Investing in training and reskilling can bridge this gap. A recent survey by DevOps Institute revealed that 72% of organizations that prioritized skill development found transitions, including to DevOps, smoother and more efficient.

Pilot Programs: Before a full-blown transition, it’s wise to run pilot programs. This involves migrating a smaller, non-critical segment of the legacy system and integrating XDR support. The lessons learned here can guide the broader migration.

Continuous Monitoring: Post-migration is not the time to be complacent. Using XDR’s monitoring capabilities, teams should continuously oversee the newly migrated segments for any anomalies or performance issues.

Infrastructure-as-Code (IaC) and Legacy Systems

Bridging the Gap with Automation: DevOps heavily leans on the principle of automation, and infrastructure-as-code (IaC) plays a pivotal role in achieving this. However, legacy systems often don’t align seamlessly with IaC principles. By using IaC platforms like Terraform or CloudFormation, organizations can create templates for legacy systems, making them more malleable for DevOps operations.

Ensuring Compliance: One challenge with legacy systems is maintaining compliance, especially when regulatory standards evolve. IaC, when coupled with XDR’s continuous monitoring, can ensure that these older systems remain compliant. According to a 2021 report by Puppet, companies that adopted IaC methodologies witnessed a 60% faster compliance update implementation time on their legacy systems.

Cultural Shifts and Organizational Dynamics

The Human Element: While the technical challenges of migration are tangible, the human element is often overlooked. Employees used to legacy systems might resist transitioning to DevOps practices, fearing obsolescence or due to comfort with older methods.

Change Management: Addressing this requires an organized change management strategy. Workshops, seminars and constant communication can assuage fears and foster a culture of continuous learning. A study by the Harvard Business Review highlighted that organizations that integrated change management strategies had a higher success rate in technical transitions, including shifts to DevOps models.

Collaborative Approach: It’s essential to foster a collaborative environment where both legacy system experts and DevOps enthusiasts work together. XDR’s collaborative tools can be instrumental here, providing a platform where teams can discuss XDR solutions, share insights and collaboratively respond to threats.

Conclusion

Transitioning from legacy systems to a DevOps model is not a mere technical challenge; it’s a transformative journey for the entire organization. The challenges, while significant, are not insurmountable, especially with tools like XDR providing support. By understanding the pitfalls and leveraging advanced solutions, businesses can ensure a smooth transition and harness the power of DevOps to its fullest.

November 7, 2023
Backslash ASPM Platform Prioritizes DevSecOps Efforts

Backslash this week made generally available a namesake application security posture management (ASPM) platform that identifies and prioritizes vulnerabilities based on how easy they are to exploit and reach.

Backslash CEO Shahar Man said the goal is to provide a comprehensive approach to providing a vulnerability exploitability exchange (VEX) platform integrated with tools for software composition analysis (SCA), static application security testing (SAST), secrets detection and creating software bills of materials (SBOMs).

That approach makes it possible to visually model threats within the context of the actual application architecture, noted Man. Armed with those insights, it then becomes possible to address cybersecurity issues by pinpointing the lines of code impacted and also identifying the developer who wrote that code.

While there is a pressing need to improve application security, current DevSecOps workflows are inefficient because there is simply too much noise, said Man. Development teams are inundated with alerts that lack any meaningful context, so after a while, they simply start to ignore them, he added.

In addition, cybersecurity teams will often create a spreadsheet with a long list of vulnerabilities to be addressed without knowing whether the code impacted is accessible via the internet or whether the code that might be affected is actually running in a production environment, said Man.

Other issues may involve transitive dependencies in open source software that developers might not even be able to address without the maintainers of those projects providing a patch.

Streamlining DevSecOps workflows has become crucial in an era where organizations are about to be held much more accountable for the security of the applications being deployed. Today, development teams are lucky if they can allocate 10% of their time to remediate vulnerabilities. Organizations need to be certain that time is spent addressing issues that could have the most impact on the business. Otherwise, a level of fatigue sets in the results in developers making the same cybersecurity mistakes time and again, noted Man.

The Backslash platform, on average, identifies one critical toxic flow for every 100 security alerts produced by other tools, he added. Once critical issues are identified, it becomes possible to more effectively apply the limited resources available to improve the overall state of application security in a meaningful way.

The debate, in the meantime, over how far left to shift responsibility for application security continues. In theory, developers are in the best position to remediate issues, but most of them have limited cybersecurity expertise. DevSecOps teams are generally going to be in a better position to identify which issues need to be addressed based on the severity of the risk they might represent. Otherwise, it’s probable IT teams will wind up wasting their time fixing issues while others that might lead to a major breach or blithely ignored.

Regardless of the approach to DevSecOps, the need for a common framework of understanding is crucial if the cultural divide between development teams and cybersecurity professionals that has existed for decades is ever going to be effectively bridged.

November 3, 2023
Software Deployment Security: Risks and Best Practices

In an era where software is at the heart of every business, deploying applications securely and efficiently has never been more critical.

From cloud-based systems that manage sensitive customer data to mobile apps that drive consumer engagement, software deployments come with a wide array of security challenges. Missteps in the deployment process can lead to disastrous consequences, ranging from data breaches to system outages.

This article covers the risks involved in software deployment and provides best practices to mitigate these dangers effectively.

What is Software Deployment?

Software deployment refers to all the processes involved in making a software system available for use. It’s a broad term that includes various stages like installation, configuration, testing and optimization. In simple terms, software deployment is the bridge that connects software developers with the end-users, allowing them to use the software product.

The primary goal of software deployment is to make a software application ready for use in a specific environment, be it a test environment, a staging environment or a production environment. It starts with installing the software system, which involves copying and configuring the software application on the servers where it will run. It then proceeds to the configuration of the software system, which involves setting the system parameters to meet the specific needs of the environment it will be running in.

Software deployment doesn’t end once the software system is up and running. It also includes monitoring and optimizing the software system to ensure it runs smoothly and efficiently. Moreover, it involves the implementation of updates and patches to fix bugs and enhance the software’s performance.

Risks in Software Deployment

Like any other process in the SDLC, software deployment comes with a set of risks that can potentially disrupt your software development projects:

Code Tampering

One of the risks in software deployment is code tampering. This happens when unauthorized individuals access the software code and alter it for malicious purposes. Code tampering can lead to the introduction of bugs, the loss of functionality or even the creation of security vulnerabilities.

To mitigate the risk of code tampering, it’s important to implement access controls that limit who can access your software code. Additionally, you should use version control systems that track changes made to your software code, allowing you to identify and rectify any unauthorized changes.

Third-Party Vulnerabilities

Third-party vulnerabilities are another risk in software deployment. These are vulnerabilities in third-party libraries and components used in your software application. If these vulnerabilities are exploited, they can compromise your software application.

To mitigate the risk of third-party vulnerabilities, it’s important to keep your third-party libraries and components up-to-date. Furthermore, you should regularly audit your third-party libraries and components for vulnerabilities and take the necessary steps to patch them.

Configuration Errors

Configuration errors are one of the most common risks in software deployment. These are errors in the configuration of the software system that can lead to the system not functioning as intended.

To mitigate the risk of configuration errors, it’s important to have a thorough testing process. This should include both functional testing to ensure the system works as intended and configuration testing to ensure the system’s configuration is correct.

Inadequate Environment Isolation

Inadequate environment isolation is another risk in software deployment. This happens when the test, staging and production environments are not properly isolated, leading to issues like data leakage or the unintentional deployment of untested code to the production environment.

To mitigate this risk, you should ensure that your test, staging, and production environments are properly isolated. This includes having separate servers for each environment and implementing access controls to prevent unauthorized access.

Lack of Monitoring

Lastly, the lack of monitoring is a risk in software deployment. Without proper monitoring, it’s difficult to identify and rectify issues in your software system.

To mitigate this risk, you should implement a robust monitoring system that allows you to track the performance of your software system. This should include error tracking to identify and rectify issues and performance monitoring to ensure your software system runs efficiently.

Common Deployment Strategies and Their Security Implications

Blue-Green Deployment

Blue-Green Deployment is a release management strategy designed to reduce downtime and risk by running two identical production environments, known as Blue and Green. At any time, only one of these environments is live, with the live environment serving all production traffic.

The primary security implication of the Blue-Green deployment is the risk of data inconsistency during the switchover. If not properly managed, sensitive data could be exposed, lost or corrupted. Furthermore, because two environments are maintained, security measures must be duplicated, potentially leading to inconsistencies and vulnerabilities if not properly managed.

Canary Deployment

Canary deployment is a strategy where new software versions are gradually rolled out to a small subset of users before being deployed to the entire infrastructure. This strategy allows teams to test and monitor the performance of the new release in a live environment with less risk.

Canary deployment can potentially expose new software versions to a smaller user base, potentially exposing vulnerabilities before a full-scale release. If a vulnerability is exploited during this stage, it could lead to a security breach affecting a subset of users. There is also the risk of vulnerabilities or malware “leaking” from the canary environment to the main production environment.

Feature Toggles

Feature toggles, also known as feature flags, allow developers to enable or disable features in a live environment. This means that new features can be deployed into the production environment but kept hidden from users until they are ready for release.

The main security risk with feature toggles is that if they are not correctly implemented, they can potentially expose unfinished or untested features to end-users, leading to potential vulnerabilities being exposed.

Rolling Deployment

Rolling deployment is a strategy where the new version of software is gradually deployed across all servers or nodes in the infrastructure, one after the other. This strategy ensures that there is always a version of the software available to users.

The primary security implication with rolling deployment is that there will be a period where different versions of the software are running concurrently. This could lead to potential vulnerabilities if the newer version has security improvements that the older version lacks.

A/B Testing Deployment

A/B testing deployment is a strategy where two versions of the software are run concurrently, with some users directed to the new version and others to the old version. This allows teams to test the performance and user acceptance of the new version before a full release.

The primary security implication of A/B testing deployment is similar to that of rolling deployment: different versions of the software running concurrently could potentially expose vulnerabilities. Additionally, directing users to different versions could potentially expose them to different levels of risk.

7 Best Practices for Secure Software Deployment

1. Code Reviews

Code reviews, also known as peer reviews, enable developers to learn from each other, enhance code quality and ensure adherence to coding standards. It’s a practice where multiple eyes scrutinize the code, spotting potential sources of vulnerabilities that a single developer might overlook.

However, code reviews are not just about hunting for bugs. They also foster knowledge sharing and collaboration amongst team members. A thorough code review process can help in identifying reusable code, reducing code complexity and increasing overall code efficiency.

2. Automated Security Scans

Automated security scans are another essential tool in your arsenal for secure software deployment. They help in identifying vulnerabilities in your code, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF) that attackers can exploit.

Implementing automated security scans in your deployment process can save you a significant amount of time and resources. It allows you to detect and fix vulnerabilities before the software is deployed, reducing the potential for security breaches.

3. Environment Hardening

Environment hardening involves taking measures to secure your system against potential threats by reducing its attack surface. It includes practices like removing unnecessary software, services, and users, setting up firewalls and configuring system permissions.

One of the most critical aspects of environment hardening is system patching. Timely patching ensures that your system is not vulnerable to known security flaws.

Moreover, environment hardening also includes measures like regular system audits and continuous monitoring. It’s not a one-time process but an ongoing effort to ensure the security of your software deployment.

4. Principle of Least Privilege

The principle of least privilege (PoLP) is a crucial principle in secure software deployment. It stipulates that a user or a process should only have the minimum privileges necessary to perform its function. This limits the potential damage in a security breach.

Implementing PoLP requires a clear understanding of your system and the roles and responsibilities of each user or process. Regular audits can help ensure that PoLP is being followed and that unnecessary privileges are revoked promptly.

5. Secure Configuration Management

Secure configuration management is an essential practice in ensuring the security of your software deployment. It involves maintaining a standard, secure configuration for your system and regularly checking and updating it to address evolving threats.

The first step in secure configuration management is establishing a baseline configuration that adheres to industry best practices. This configuration should then be applied to all systems.

Regular audits should be conducted to ensure systems adhere to the baseline configuration. Any deviations should be promptly identified and rectified.

6. Immutable Deployments

In an immutable deployment, once a version of the software is deployed, it is never modified—any changes cause a new version of the software to be deployed. This approach reduces the risk of configuration drift and makes your deployments more predictable and reliable.

While implementing immutable deployments may require a shift in your deployment practices, the security and reliability benefits are significant. It can also help simplify the deployment process and make it more efficient.

Mastering the art of software deployment is a journey that involves the careful implementation and continuous improvement of various practices. While the road may seem long and winding, the destination—a secure and efficient software deployment process—is well worth the effort.

November 2, 2023
Digital.ai Update Extends Scope and Reach of DevSecOps Platform

Digital.ai this week made generally available a Denali update to its DevSecOps platform that promises to make it simpler to integrate custom artificial intelligence (AI) models with the AI models developed by the company.

At the same time, the company is adding self-guided workflows and templates to generate tests and implement DevSecOps best practices along with integrations with Terraform by Hashicorp, Azure Bicep, Azure Key Vault and AWS Secrets Manager.

Finally, Digital.ai is adding an ARM Protection feature to better secure iOS applications without requiring embedded bitcode or integrations into the build system. DevOps teams can, via a single command, protect compiled applications locally with support for obfuscation, run-time active protections and application monitoring without uploading them to a third-party service.

Greg Ellis, general manager for application security for Digital.ai, said the overall goal is to make it simpler for software engineering teams to invoke capabilities that have been embedded within the company’s DevSecOps platform.

In the case of AI models, that also means instead of requiring DevOps teams to only use AI models developed by Digital.ai, the company is moving to make it simpler for DevOps teams that adopt its platform to incorporate custom AI models as they see fit as part of an ongoing effort to democratize intelligence at scale, he noted.

In general, it’s already apparent organizations will be employing heterogeneous approaches to incorporating AI models into DevOps workflows, said Ellis. The challenge now is moving beyond experimenting with AI to embedding them within DevOps workflows, he added.

It’s already clear developers are using generative AI to develop code at increasingly faster rates. The challenge now is to manage that accelerated pace of development when many organizations are already struggling to manage existing DevOps workflows at scale. Hopefully, AI technologies will also one day help software engineers find ways to manage that volume of code moving across their DevOps pipelines.

In the meantime, organizations will also need to better define where the machine learning operations (MLOps) workflows that data scientists use to build AI models end and where DevOps workflows that will be used to embed AI models into applications begin. As is often the case when it comes to emerging technologies, cultural issues are just as challenging as the implementation hurdles that need to be overcome.

At this point, like it or not, the generative AI genie is out of the proverbial bottle. Just about every job function imaginable will be impacted to varying degrees. In the case of DevOps teams, the ultimate impact should involve less drudgery as many of the manual tasks that conspire to make managing DevOps workflows tedious are eliminated. Less clear is to what degree AI may drive organizations that have already embraced DevOps to adopt an alternative platform, but savvy DevOps teams are, at the very least, starting to map out which processes are about to be automated so they can have more time to focus on issues that add more value to the business.

October 27, 2023
OpsMX Adds Deployment Firewall to Ensure Compliance

OpsMx today added a deployment firewall to its Deploy Shield portfolio for securing continuous integration/continuous delivery (CI/CD) platforms.

The deployment firewall automatically applies rules to ensure DevOps teams comply with mandates such as the payment card industry data security standard (PCI DSS) or the Health Insurance Portability and Accountability Act (HIPAA). It then evaluates a release against a checklist of policies and blocks any deployments into a production environment unless a specific exception has been defined. In those instances, DevOps teams can also set an alert to address that issue at a later date.

In addition, DevOps teams can extend those rules defined by OpsMX to address specific compliance requirements.

The checklist includes making sure vulnerability scams have been run, tracking when the manifest was last updated, confirming that operational controls are being followed, checking whether images have been modified and evaluating the infrastructure being employed and performing an analysis of the performance impact.

A simulation feature also allows developers to check their release for compliance before it is time to deploy.

OpsMx CEO Gopal Dommety said the goal is to streamline the effort that is required to meet multiple compliance mandates as the pace at which applications are being developed and deployed continues to increase.

Today there are simply too many data silos for DevOps teams to manage, with each one presenting yet another opportunity to run afoul of a compliance mandate, he added. The overall goal is to reduce the cognitive load being placed on developers as more responsibility for compliance is shifted left, noted Dommety.

The deployment firewall currently supports DevOps platforms such as Jenkins, Argo and Spinnaker, with support for GitHub Actions and GitLab to follow.

OpsMX claims its overall customer base has increased by more than 60% in the first half of this year, with customers including Google, Cisco and Western Union. In addition to Deploy Shield, the company provides a Delivery Bill of Materials (DeliveryBOM) tool to capture a consolidated record of every step in the application software delivery and deployment process. Security checks, approvals, policy enforcement and audits are tracked via one tool. In addition, the company provides tools for managing the deployments of software via either the Argo or Spinnaker CD platforms.

It’s now only a matter of time before various regulations that apply to the building and deploying applications become more stringent. Tolerance for sloppy application development processes is dropping as legislative bodies increasingly determine that software development practices are a big cybersecurity problem that threatens national security and the global economy.

Organizations that fail to comply with those regulations will be subject to even heftier fines than the ones that already exist. In many cases, that may slow down the rate at which applications are deployed unless DevOps teams find ways to manage compliance-as-code more effectively as part of a larger DevSecOps workflow.

When it comes to DevSecOps, progress tends to be slow in most organizations, but as more tools become available to automate various tasks, it’s now only a matter of time before software supply chains are more tightly secured. Hopefully, the pace at which those advances are being made will occur faster than cybercriminals can exploit the vulnerabilities that today are too numerous to manually track.

October 23, 2023

←Previous Page

1 … 29 30 31 32 33 … 88

staging-devopsy.kinsta.cloud

Where the world meets DevOps

Blog
About
FAQs
Authors

Events
Shop
Patterns
Themes

Twenty Twenty-Five

Designed with WordPress

[wpp_insert]

Modern Software Development and Delivery

1Q1

2Q2

3Q3

4Q4

5Q5

6Q6

How would you best describe your organization's current software delivery environment(s) on mainframe computers? (Select all that apply)(Required)

Primarily manual or legacy delivery processes

Automated CI/CD in limited areas

Hybrid environment with multiple delivery platforms and toolchains

Mostly standardized CI/CD platform

Intelligent, governed software delivery platform

My organization does not utilize mainframes

Not sure / don't know

Which outcomes are most important to your organization's software delivery strategy today? (Select up to three)(Required)

Accelerating software delivery

Automating build, test, and deployment workflows

Integrating security and compliance into delivery

Providing governance and auditability

Supporting AI-assisted software delivery

Improving software supply chain visibility

Standardizing delivery across teams

Supporting both modern and legacy application delivery

Other

Not sure / don't know

What, if anything, is limiting your organization's mainframe software delivery progress? (Select up to three)(Required)

Legacy applications or legacy development processes

Fragmented tools and disconnected workflows

Security, governance, or compliance requirements

Limited automation across the delivery lifecycle

Difficulty integrating AI into software delivery workflows

Skills or resource constraints

Organizational or cultural resistance to change

Limited visibility across the software delivery lifecycle

Budget or investment constraints

Other

Nothing is significantly limiting our progress

Not sure / don't know

In which areas of your mainframe software delivery environment are you currently using AI? (Select all that apply)(Required)

Code generation / developer assistance

Automated testing / test generation

Build and pipeline optimization

Deployment automation

Monitoring and incident response

Security / compliance automation

Other

We are not currently using AI in our environment today

As software delivery responsibilities expand beyond traditional build, test, and deploy, which of the following areas is the most challenging for your organization today with respect to mainframe software delivery? (Select one)(Required)

Integrating security throughout the software delivery lifecycle

Meeting governance, audit, or compliance requirements

Managing software supply chain integrity and visibility

Operationalizing AI across software delivery workflows

Coordinating software delivery across diverse tools, teams, and environments

Other

None of these are significant challenges

Not sure / don't know

Which of the following do you expect is most likely to accelerate your organization's mainframe software delivery progress over the next 12-18 months? (Select one)(Required)

Greater automation across the software delivery lifecycle

Broader use of AI-assisted software delivery workflows

Stronger governance, policy, and compliance automation

Improved software supply chain visibility

Better integration across software delivery tools and platforms

Greater standardization across development teams

Other

No significant changes are planned

Not sure / don't know