devopsy.kinsta.cloud

Tag: devsecops

  • Software Supply Chain Risk Management: A 2023 Guide

    Software Supply Chain Risk Management: A 2023 Guide

    Software supply chain risk management (SSCRM) refers to the process of identifying, assessing and mitigating risks associated with third-party software components and services that are integrated into software products. SSCRM involves understanding the potential vulnerabilities that may arise from these components and taking measures to reduce the risk of exploitation or compromise to the software system or end-users.

    Why Software Supply Chain Attacks are Becoming More Common

    Software supply chain attacks have become common due to several factors: 

    • Larger attack surface: The increased use of third-party software components and services in software development has expanded the attack surface for cybercriminals. This means that attackers can exploit vulnerabilities in these third-party components to gain access to the larger software system. 
    • Rise of open source: The proliferation of open source software has also contributed to the rise of supply chain attacks as attackers can inject malicious code into open source repositories, which can then be used by developers in their software products.
    • Difficulty to detect: Detecting supply chain attacks can be challenging since attackers often use legitimate-looking code that may be difficult to distinguish from normal code. This can make it difficult for traditional security measures to detect the attack. Additionally, the attack may not manifest itself until much later, making it even harder to trace back to its source.
    • Automation: Supply chain attacks are also becoming more sophisticated through the use of automation. Attackers can use automated tools to scan for vulnerabilities in third-party components and inject malicious code into them. This means that they can quickly and efficiently compromise a large number of software products.
    • Evasion techniques: Attackers can evade traditional security measures through techniques such as code obfuscation and encryption. This makes it difficult for security measures to detect malicious code, which can easily slip through undetected.
    • Sophistication: Supply chain attacks are becoming more challenging to combat due to the use of advanced malware techniques to change shape. Attackers can use polymorphic malware that can change its code and behavior to avoid detection. This means that even if the malware is detected, it can quickly change its form to evade detection in the future.

    Supply Chain Security and DevSecOps

    DevSecOps is an approach that integrates security into all stages of the software development process. Adopting DevSecOps practices can help businesses manage supply chain risks by building security into their software development and delivery pipelines. 

    Continuous integration/continuous deployment (CI/CD) pipelines are a key component of DevSecOps, as they allow developers to rapidly test and deploy code changes while ensuring that security and compliance requirements are met.

    Here are some ways DevOps tools in the CI/CD pipeline can help manage supply chain risks:

    • Automating security testing: DevSecOps enables businesses to automate security testing throughout the software development life cycle, including during the development, testing and deployment phases. This can help identify and mitigate security vulnerabilities early in the process, reducing the likelihood of supply chain risks.
    • Continuous monitoring: DevSecOps enables continuous monitoring of software and infrastructure, providing real-time visibility into the security posture of the supply chain. This can help identify and respond to security threats quickly and effectively.
    • Secure coding practices: DevSecOps encourages the use of secure coding practices, such as input validation, access control and error handling, reducing the likelihood of supply chain risks.
    • Risk management: DevSecOps incorporates risk management into the software development process, ensuring that supply chain risks are identified, assessed and managed effectively.

    Tools and Solutions to Help Manage Supply Chain Risks

    Supply Chain Risk Management (SCRM)

    SCRM solutions are software tools and services that help organizations manage and mitigate supply chain risks. These solutions provide visibility into the supply chain operations, identify potential risks and enable organizations to take proactive measures to mitigate these risks. 

    They may include features such as supplier risk assessments, real-time monitoring of supply chain operations, analytics and reporting and incident response planning. SCRM solutions are often available as a service (SaaS) and can help organizations to enhance supply chain resilience, reduce disruption and ensure business continuity.

    Software Composition Analysis (SCA)

    Software Composition Analysis (SCA) is a software security practice that involves identifying and managing open source and third-party components used in the development of software applications. SCA tools scan the software codebase, detect and report the presence of third-party and open-source components and identify known vulnerabilities in these components. 

    SCA helps organizations to identify and manage risks associated with third-party components, including license compliance, intellectual property infringement and security vulnerabilities. SCA is an essential component of SSCRM and can help organizations to ensure the security and integrity of the software products they develop and distribute.

    Third-Party and Supplier Risk Management

    Third-party and supplier risk management software is designed to help businesses manage the risks associated with their third-party vendors and suppliers. This software provides tools and resources to identify, assess and manage the risks associated with third-party relationships.

    Here are some features of third-party and supplier risk management software:

    • Supplier management: The software provides tools to manage supplier relationships, including supplier performance monitoring, supplier compliance and supplier risk assessment.
    • Risk assessment: The software enables businesses to assess the risks associated with their third-party relationships, including financial risks, operational risks and reputational risks.
    • Compliance management: The software helps businesses comply with regulations and standards, such as GDPR, HIPAA and ISO 9001.
    • Data analytics: The software uses data analytics tools to help businesses identify trends and patterns in third-party data, enabling them to anticipate and mitigate risks.
    • Incident management: The software provides tools to help businesses respond to and manage incidents related to third-party relationships, such as data breaches or compliance violations.

    Best Practices for Software Supply Chain Risk Management

    The following are some best practices for managing supply chain risks.

    Identifying Supply Chain Threats and Potential Weaknesses

    The first step in managing supply chain risks is to identify potential threats and vulnerabilities in the supply chain. This involves conducting a comprehensive risk assessment that considers all potential sources of risk, including geopolitical factors, natural disasters, cyber threats and other disruptions. The risk assessment should consider the entire supply chain, including all vendors, suppliers and partners.

    During the risk assessment, organizations should identify the critical components and services that are essential to their operations. They should also evaluate the potential impact of a disruption to these critical components and services, including the financial, reputational and operational impact.

    Establishing a Supply Chain Risk Management Framework

    After identifying potential threats and vulnerabilities, organizations should establish a supply chain risk management framework that outlines the policies, procedures and controls required to mitigate these risks. The risk management framework should be aligned with the organization’s overall risk management strategy and should include the following components:

    • Risk management policy: This policy should outline the organization’s approach to supply chain risk management and define the roles and responsibilities of key stakeholders.
    • Risk assessment procedures: These procedures should describe how the organization conducts risk assessments, including the criteria used to evaluate risks and the frequency of assessments.
    • Risk mitigation controls: These controls should outline the specific measures the organization will take to mitigate identified risks.
    • Incident response plan: This plan should describe the steps the organization will take in the event of a supply chain disruption.

    Continuously Monitoring Risks

    Once the supply chain risk management framework is in place, organizations should continuously monitor supply chain and third-party risks and take proactive measures to mitigate them. This includes establishing a patching cadence to ensure that all software components are up to date and protected against known vulnerabilities.

    Organizations should also implement endpoint security controls, such as antivirus software and intrusion detection systems, to protect against malware and other cyber threats. Network security controls, such as firewalls and access controls, should be implemented to protect against unauthorized access to systems and data.

    Web application security controls should also be implemented to protect against web-based attacks, such as SQL injection and cross-site scripting. This includes conducting regular vulnerability assessments and penetration testing of web applications.

    Promoting a Culture of Awareness

    Finally, organizations should promote a culture of awareness among all stakeholders, including employees, vendors, and suppliers. This includes providing risk awareness training to employees, so they understand the risks associated with the supply chain and the steps they can take to mitigate these risks.

    Organizations should also communicate their supply chain risk management policies clearly to vendors and suppliers so they understand their obligations and responsibilities in managing supply chain risks. This includes conducting due diligence on vendors and suppliers to ensure they meet security standards and policies.

    Conclusion

    Managing supply chain risks is a critical task for organizations that rely on third-party vendors and suppliers to deliver goods and services. These risks can arise from a range of sources, including geopolitical factors, natural disasters, cyber threats and other disruptions.

     To effectively manage these risks, organizations need to adopt best practices such as identifying threats and potential weaknesses, establishing a supply chain risk management framework, continuously monitoring risks and promoting a culture of awareness.

    As we look ahead to 2023, it is clear that software supply chain management will continue to be a priority for organizations across industries. With the increasing complexity of software supply chains and the evolving threat landscape, organizations must remain vigilant in their efforts to identify and mitigate potential risks.

  • How to Maximize Telemetry Data Value With Observability Pipelines

    How to Maximize Telemetry Data Value With Observability Pipelines

    The software landscape has shifted significantly in recent years as companies digitize their operations and adopt cloud and microservices technologies. The complexity of modern software systems has led to an increasing need for real-time visibility into their performance—resulting in an explosion of telemetry data that is stretching IT budgets and outpacing engineering teams’ ability to find value in that data. In fact, data volume is growing at 23% yearly, while IT budgets are only growing at 5%.

    Managing all this data at increasing cost is further compounded by unpredictable software failures and ever-evolving security threats. As a result, companies are forced to pick which parts of their software to instrument and monitor. To overcome this challenge, a different approach to managing data is required.

    Observability pipelines are emerging as a way to address this problem. They centralize telemetry data (i.e., logs, metrics and traces) from many sources, transform that data to fit downstream needs, and route it to various destinations for analysis. With complete control of the data, companies can sort through large amounts and prioritize what is essential, allowing them to act swiftly to avoid disruptions while reducing costs by only storing the data they need.

    Research indicates 62% of organizations currently have an observability practice. This means 38% operate with limited awareness of what’s happening in their software. Even those with an observability practice can only afford to store some data and have to choose which applications to instrument. This leads to blind spots and, ultimately, issues that are time-consuming to fix due to a lack of data.

    Managing Limited Resources With Observability Pipelines

    Engineers face more demands in today’s fast-paced business environment than ever before. Despite an increase in their responsibilities, the size of engineering teams has yet to grow accordingly. Given this, there has been a rise in full-stack engineers responsible for technologies from the front end to the back end. Short on time and resources, it’s difficult for these engineers to instrument and monitor software.

    Observability pipelines help control the amount of telemetry data using various processors such as sampling, throttling, filtering and parsing, and only forward valuable data to the downstream systems. The rest of the data can either be discarded or stored in a low-cost system, such as Amazon S3. This reduces costs and lets engineers focus on analyzing relevant data to identify issues.

    Engineers can also use observability pipelines to consolidate data from various tools. Many teams use different platforms or open source tools, like Prometheus or Jaeger. The fragmented data makes it hard to solve issues and understand application health. Observability pipelines combine all this data to make it easier to act on.

    It’s also important to remember that real people work on these technical challenges. Engineers face burnout working long hours to keep up with software development demands. Constantly switching between tools and manually moving data adds to the pressure. Moreover, the number of data sources, observability tools, and platforms that need that data are constantly increasing. Embracing open standards such as OpenTelemetry can ease this integration burden. Engineers can swap out tools without extensive testing and integration. The increased control and easy integration enable engineers to focus on delivering business value.

    Making Data More Usable

    Teams across organizations want access to data but struggle to use it effectively. The difficulty stems from the lack of data usability: Telemetry data is unstructured; varying formats make it hard to use; data preparation is time-consuming and sensitive data in logs may lead to compliance violations.

    By most estimates, 80%-90% of data is unstructured, which makes it hard to store and analyze because it doesn’t adhere to traditional data models. Observability pipelines make sense of unstructured data before it reaches its final destination. This is achieved using data processors that shape and transform data to make it more actionable. These processors include advanced parsers that identify and extract relevant information, transforming data into consumable formats that make it easier to work with and analyze.

    The advantage of performing these operations within the pipeline is that the same data can be prepared to fit different use cases downstream. For instance, while one team may require data optimized for visualization and trend analysis, another may require complete data for threat hunting. These transformations are managed from a single control point, eliminating the need to maintain separate data streams.

    Observability pipelines can also help companies meet data compliance requirements. For example, teams can scrub, mask or redact PII data based on a defined key structure before the data reaches a SIEM or audit platform.

    Taking Immediate Steps to Make the Most of Telemetry Data

    Organizations can take immediate action to make the most of their telemetry data. First, they need to adopt a visibility-first rather than a cost-first approach. They should assess what software they’ve instrumented. This will identify gaps in telemetry, which can be used to develop a plan to instrument all software. Next, they need to create a strategy for managing their telemetry data, being particularly thoughtful about how and why the data is stored and analyzed.

    Once a company has taken these two steps, it can decide which tools to use. One of the great things about OpenTelemetry is that it provides flexibility for future decisions about what tools to use.

    As companies invest more resources into building observability practices, they’ll encounter problems processing an extraordinary amount of telemetry data for any meaningful action. Observability pipelines provide a competitive advantage of prioritizing the essential data that will enable companies to make better decisions faster.

  • Awareness of Software Supply Chain Security Issues Improves

    Awareness of Software Supply Chain Security Issues Improves

    A global survey of 167 software professionals suggested that, while there is a lot more awareness of application security issues, the adoption of DevSecOps best practices is still not pervasive.

    The survey, conducted by Chainguard, the Eclipse Foundation, the Rust Foundation and the Open Source Security Foundation (OpenSSF), found that just over half (51%) of respondents are either concerned or are extremely concerned about software supply chain security.

    In addition, only a third of respondents (33%) reported they are familiar with the Supply-chain Levels for Software Artifacts (SLSA) framework for building more secure applications. Well over a third (36%), however, said they had never heard of it.

    Only a quarter of respondents (25%) reported that their team always signed built artifacts, the survey found.

    The survey identified the most challenging issues developers are encountering and found they are reproducing builds (64%) followed by creating hermetic builds that are isolated from other software libraries (62%).

    Mikaël Barbero, head of cybersecurity for the Eclipse Foundation, said while awareness of software supply chain issues is higher, it’s apparent that other priorities are still getting in the way of adoption of DevSecOps best practices. For example, software bills of materials (SBOMs) may generate a lot of headlines, but their adoption remains mixed, he added.

    John Speed Meyers, a security data scientist for Chainguard, noted that incentives still need to change; too many managers that hire developers still emphasize performance and delivery times over application security. Many developers, as a result, still tend to view cybersecurity as an obstacle to be overcome or worked around rather than a core capability that they will be graded on, he added.

    In theory, as responsibility for application security shifts left toward developers, overall cybersecurity will improve. Most developers, however, have little to no cybersecurity training, so the odds they will be able to resolve these issues are low. Instead, many organizations are either trying to embed cybersecurity professionals within DevOps workflows or, at the very least, deputize at least one developer to advocate for cybersecurity within those teams.

    Regardless of commitment level, it’s apparent that organizations need to address everything from locking down developer environments to thwart phishing attacks to ensuring application builds are not inadvertently infected with malware. The challenge organizations face is both technical and cultural, so the amount of effort required should not be underestimated.

    In the meantime, organizations should expect to see cybercriminals increase their attempts to compromise software supply chains. Infecting malware into software components that will be used by multiple downstream applications is, from their perspective, one of the most efficient means of wreaking havoc. Right now, organizations make it too easy for cybercriminals to compromise application environments.

    Organizations should also recognize that tolerance for insecure applications is also declining, as evidenced by the National Cybersecurity Strategy put forward by the Biden administration. It’s not so much a question of whether organizations that create software will be held liable for application security issues as much as it is to what degree.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    CVS Health
    Remote
    Lead Director – Enterprise Digital Security
    $140,000 to $280,000

    Indeed.com

    Splunk
    Remote
    DevOps and Observability Assigned Expert
    $143,200 to $196,900

    SimplyHired

    Book of the Month
    New York, New York
    Senior DevOps Engineer
    $140,000 to $180,000

    Monster.com

    Innova Solutions
    Plano, Texas
    DevOps Engineer
    $110,000 to $130,000

    Dice.com

    Solaris Finserv
    Kennesaw, Georgia
    DevOps Engineer
    $100,000 to $120,000

  • DevSecOps Provides a Modern Security Model for Modernization

    DevSecOps Provides a Modern Security Model for Modernization

    Developers and security experts are now tasked with bolstering, extending and adjusting cloud and Kubernetes security to protect against cyberattacks that are ever more complex, volatile, and frequent. To foil attacks and create a secure foundation for applications and infrastructure from the beginning, DevSecOps (development, security and operations) has become the trending development and operations practice. In the DevSecOps model, security becomes a shared responsibility. Thus, DevSecOps requires a mindset shift to enable collaboration between development, security and operations teams. This shift, commonly referred to as shift left, involves culture, processes and tools. With DevSecOps, whether it’s testing for security vulnerabilities or building security services that can be used directly for business purposes, the goal for all participants is to build security into applications from the start and throughout the continuous integration and continuous delivery (CI/CD) workflow of DevOps.

    DevSecOps to the Rescue

    In the past, security considerations and practices were often introduced at the end of the development cycle by a separate security team and tested by a separate (QA) team. This was manageable when software updates were released every few months or even years. But in today’s landscape, consumer habits and expectations are shaped by smartphones and digital commerce, which has fueled the demand for software services that are real-time and available 24/7. This requires modern enterprises to find ways to improve the efficiency of application developments, releases, and updates.

    Because of these factors, enterprises realize that security can no longer be a small part of an afterthought in the production environment. The purpose of DevSecOps is to ensure that through collaboration, security can be carried through to every point in the development cycle. This enables teams and enterprises to deliver secure, high-quality applications in a more efficient manner without extensive security checks and fixes occurring during post-production.

    To meet these more extreme demands, cloud computing, containers, and microservices have made it possible to accelerate the development and delivery of software releases. Developers adopting agile and DevOps practices can reduce software development cycles to days and weeks, thus meeting the diverse needs of enterprises and users.

    This fast-paced development and upgrade frequency has created new security concerns and the need for companies to be more agile in responding to security issues. DevSecOps has been introduced into the DevOps framework to meet these needs by make security a shared responsibility. Today, continuous testing and integration, including security scanning of pipelines, is becoming the norm.

    DevSecOps Business Benefits

    In principle, DevSecOps shares the DevOps ideal of multiple teams working together to improve team efficiency and achieve secure, continuous software delivery.

    In addition to the security benefits DevSecOps provides, there are significant business advantages to be gained, including:
    ● Efficiency–Under the DevSecOps practice, security is integrated into all periods of development to help all teams be more agile in responding to security risks, eliminating the need for teams to spend a lot of time tweaking and fixing during the production cycle.
    ● Cost reduction–By discovering security vulnerabilities before they enter production, organizations and teams can significantly reduce the time and labor costs of fixing them.
    ● Ensure compliance–DevSecOps can ensure compliance with industry-standard regulations, such as the General Data Protection Regulation (GDPR). DevSecOps gives teams a holistic overview of these measures that makes compliance easier.
    ● Establishes collaborative culture–Integrating security practices into DevOps enhances the value of DevOps and improves the overall security posture as a culture of shared responsibility. When everyone is involved in the process, it increases their awareness of security fundamentals and best practices and provides a sense of ownership in the results.

    Meeting New DevOps Challenges

    Kubernetes offers many advantages but also poses unique security challenges that can be difficult to address for organizations lacking in Kubernetes talent and experience. This is why organizations will increasingly see the need to reevaluate their security practices and prioritize a more advanced security-focused culture.

    Because DevSecOps requires security to be addressed throughout all development stages, it requires developers to have security expertise while coding and operating. We are currently seeing a growing skills gap in the DevOps industry, and developers are feeling burned out. Security training is a way for teams adopting DevSecOps to acquire additional knowledge.

    Deploying Kubernetes platforms with security built in by default also will be recognized as a means to reduce the burden of security on IT teams. This will reduce the pressure and burnout on all sides.

    Platform Engineering Provides Additional Help

    With the rapid development of Kubernetes and cloud-native applications, organizations are realizing the inadequacies of their IT teams to leverage DevOps practices. Just as platform engineering eases the burden of DevOps by providing an Internal Development Platform (IDP) that serves as a “golden path” for developers, an IDP can simplify the practice of DevSecOps.

    We’ve seen that a DevOps workload is difficult to practice in small and medium-sized enterprises, as well as in large enterprises that lack sufficient talent. The gradually accumulated cognitive load ultimately leads to a less agile and efficient collaboration between teams. Given these issues, more organizations will adopt platform engineering as a better alternative.

  • Good Things Happen When DevSecOps and Cloud Collide

    Good Things Happen When DevSecOps and Cloud Collide

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

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

    Software: A World of Consistent Change

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

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

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

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

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

    How to Take Advantage of the Collision

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

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

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

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

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

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

  • Survey: More Cybersecurity Pros Embedded in DevOps Teams

    Survey: More Cybersecurity Pros Embedded in DevOps Teams

    A survey of 2,500 C-level executives published today by Palo Alto Networks found 81% of organizations have embedded cybersecurity professionals within their DevOps teams.

    Despite the presence of those cybersecurity professionals, however, the survey also suggested there is much work to do in terms of optimizing DevSecOps workflows. A full 90% of organizations cannot detect, contain and resolve cybersecurity threats within an hour, the survey found.

    Bob West, chief security officer for Palo Alto Networks, said most of the challenges associated with DevSecOps are directly related to persistent cloud security issues. More than three-quarters of organizations (78%) said they had distributed responsibility for cloud security, but almost half (47%) said a majority of their workforce still does not understand their security responsibilities.

    In many cases, developers with little to no cybersecurity expertise are responsible for provisioning cloud infrastructure. As a result, misconfigurations that create security issues are commonplace, noted West. That’s especially problematic because three-quarters of organizations (75%) are deploying new or updated code to production weekly, with almost 40% committing new code daily, the survey found. Given that developers far outnumber cybersecurity professionals in most organizations, it remains challenging to ensure application code is secure, noted West.

    In addition to improving the overall state of cloud security, organizations need to focus on fundamentals such as training developers to be more mindful of cybersecurity issues, he added. Most developers never had any formal cybersecurity training, so it’s up to organizations to make sure that particular skills gap is closed, he noted. In addition, organizations need to make sure they have a robust set of patch management processes in place alongside a capability to manage permissions and entitlements, added West.

    Overall, the survey found organizations are using more than 30 security tools, on average, including six to 10 dedicated to cloud security. More than three-quarters of respondents (76%) said relying on multiple security tools created blind spots that affected their ability to prioritize risk and prevent threats. A full 80% said they would benefit from a centralized security solution that sits across all of their cloud accounts and services.

    One way or another, a rising tide of regulations focused on improving the security of software supply chains will force organizations to improve cloud security, said West. The survey showed there is a strong commitment in terms of making cybersecurity professionals an integral part of a DevOps workflow. The issue is that there are still a raft of training and process issues that need to be addressed at a time when cybercriminals are becoming increasingly adept at compromising applications both as they are developed and after they are deployed.

    Of course, training and modifying processes take time. DevSecOps is as much about changing culture as it is about acquiring new tools. DevOps teams are still highly committed to building and deploying applications as quickly as possible. The challenge is finding a way to insert a set of cybersecurity gates within those workflows without slowing down the pace at which applications are developed.

  • Benefits and Challenges of DevSecOps for Business

    Benefits and Challenges of DevSecOps for Business

    Almost every day, there is a new tactic or technique discovered that hackers can use to disrupt a company’s systems, obtain critical data and information or steal money. Often attackers look to exploit vulnerabilities in code to carry out their attacks. Ironically, it’s usually a small piece of code that helps a business perform very simple tasks that can become the root of this serious issue (e.g., logging, report service and glue for application). In fact, it only takes one exploitation, vulnerability or human error to cause a data breach that, on average, costs $4.35 million. Some experts projected that by 2025, these breaches could cost a total of $10.5 trillion. Therefore, CEOs and other corporate executives should reflect on these incidents to ask themselves what would happen if someone entered their systems to exploit code and what it could mean for their company.

    The Problems That a Business Faces

    In traditional development practices, security serves a ‘gating’ function. Security checks are performed prior to releasing an application to production and, if issues are found, security stops rollouts. This can have disastrous ramifications.

    The unknown can be frightening, but that’s where DevSecOps can help. DevSecOps incorporates security into every step of the software development life cycle (SDLC) from requirements to architecture and design, coding, testing, release and deployment. By automating and integrating security practices into the software development life cycle, development teams can react to vulnerabilities sooner, automate security checks and proceed into production with a more reliable and secure product.

    The benefit is felt when a tactical vulnerability is discovered and the DevSecOps practice is already in place to ensure that it can be remediated with limited impact on the business.

    The Business Benefits of DevSecOps and Best Practices

    Streamlining the SDLC and including security checks (often automated) in the process early in the development cycle can identify a problem before it can negatively affect the bottom line of the development effort and the business. Having a vulnerability remediated early in the development cycle is an order of magnitude less expensive than one discovered just prior to production.

    DevSecOps works best in an organization where Agile practices have been adopted to swiftly enable continuous integration, deployment and scalability. The road to streamlining and automating these practices can be long, but when effectively applied, DevSecOps best practices reduce costs for the company and accelerates time to market.

    For DevSecOps to be effective, security must have a seat at the table when requirements are gathered and architectures are planned. This integration of work practices ensures that risks are identified early and can be mitigated well before an application is launched in production.

    Using that same connection with operations, security procedures should be established to feed new vulnerability discoveries into the pipeline for remediation. However, implementing DevSecOps isn’t a magic fix and it won’t happen immediately. But why can it be so hard to implement?

    Overcoming the Challenges of DevSecOps

    There are many difficulties when it comes to implementing DevSecOps. Here are two of them:

    1. Cultural Shift:
    Leading with a DevSecOps approach requires a huge culture shift within the organization that challenges the way many departments operate today. Many employees might find it difficult to drastically change what they’ve been doing for years. Another roadblock is the belief that better protection slows down processes and restricts innovation. Quick code production is a goal for developers who want to meet the demands of businesses, while on the other hand, security teams are focused on making sure the code is secure.

    Thorough training for both security and development experts will help overcome some cultural obstacles but integrating the goals and objectives of both teams will push the adoption of DevSecOps practices. Organizations will begin to see security align to faster time and flexibility of solutions while developers will begin to adopt a security-first mindset.

    2. Complex Tool Integrations:
    Most DevOps toolchains are produced by different vendors. Teams select source code management, continuous integration/delivery (CI/CD), build tools, binary libraries, code review and problem monitoring solutions based on their unique needs. Adding security tools into that pipeline can create a challenge for ensuring the best results for both teams.

    Security analysis in the development pipeline is done with tools that perform software composition analysis (SCA), static application security testing (SAST), and some form of dynamic testing. Integration into the pipeline of these tools is significant and creates difficulties for developers. The developer must know the intent of the scan and what to do with the problems they uncover. It is important that developers have an accurate understanding of where the problem arose and what the issues mean. However, combining and comparing the results and data of many vendors’ resources might be challenging.

    The best course of action would be to consolidate your solutions. This will not only make things simpler for the developer and the organization, but it may also reveal threats that the organization wasn’t previously aware of.

    Overcoming these obstacles is not an easy task, but it is possible. Once a DevSecOps approach is accepted and fully implemented across your company, you can expect code to be developed with fewer bugs and security risks. The cost of deploying code will also eventually decrease, and at a pace that helps the organization maximize its return on investment. Overall, systems created within this process will be significantly more flexible and capable of adjusting to modern-day threats and change in the midst of a digital transformation.

  • Leveraging Automation for Secure, Cost-Effective Mobile App Delivery

    Leveraging Automation for Secure, Cost-Effective Mobile App Delivery

    As businesses mobilize their customers and employees, they need to develop innovative mobile applications that safeguard user trust. But secure mobile development and manual security testing can be expensive and time-consuming—a bigger challenge in slowing economies. However, the latest innovations in security automation for mobile teams can drive down security costs by half while speeding release time, getting quality mobile apps to market faster to grow revenue faster.

    With mobile dominating all digital time spent online versus the web, businesses cannot compromise the safety of their mobile users and mobile data. Security automation integrated throughout the development process empowers developer, QA and security teams’ efficiency, enabling faster release cycles with built-in security. This approach powers success for digitally enabled businesses that depend on mobile apps to generate revenue, engage customers and tap new markets.

    A single security vulnerability within a mobile app can instantly damage a business’s financial stability, brand reputation and customer trust. Even highly respected brands like UnderArmour and British Airways experienced serious issues after their mobile apps were breached. Business leaders should consider the benefits of adding security automation directly into the development pipeline to drive quality and protect users in a cost-effective manner.

    Faster, Lower Cost Developer Cycles

    Suppose a business creates a 12-week plan to develop, test and release a mobile app software update with a labor budget of $60,000 per week. The development team creates a schedule to write the code in 10 weeks and allocates a two-week period for a manual security pentest. After developers finish writing the code, they must wait for the pentest results to point out any security issues. When testing uncovers security issues, devs, security analysts and QAs must determine which issues need to be remediated. Then the devs can fix the issue, retest to ensure it is properly fixed, then release it. Most of the time, finding any issues delays the release by weeks or months, delaying the expected revenue generation and other business benefits by weeks or months, in turn.

    Instead, businesses can take a cost-effective approach by running security automation continuously through the development life cycle. Dev teams can write code, allow security automation to run during off hours, and have tickets with built-in remediation info sent back to devs the next day. This can remove weeks of testing and remediation delays to ensure teams release on time and on budget. Businesses can cut costs further by establishing common coding, testing and remediation policies in advance and then deploying an automated policy engine to focus on just those security requirements and issues relevant to the policy to operate at the fastest pace possible.

    Integrating automated security testing into development tools enables DevSecOps teams to build, test, fix and release faster with security built in. Not only does this strategy increase the security and quality of the mobile app, it drastically lowers development costs by improving team efficiency.

    Faster, Lower Cost Security Testing Cycles

    Every organization with a mobile app has different security requirements. Those with low-risk mobile apps may outsource their security testing once or twice a year. Those in highly regulated industries like healthcare and financial services may have internal security analysts and test as often as every release and event outsource pen testing quarterly. Whether testing internally or externally, security testing costs can become a major pain point for companies looking to manage their finances efficiently.

    The average cost of a full-scope, two-week outsourced manual pentest costs around $15,000 to $20,000 per test. If an organization tests its mobile app on a quarterly basis, its pentesting costs jump to $60,000 to $80,000 per year. Internal pentesting teams can potentially be cheaper, but organizations still need to pay for analysts’ salaries and the tools and resources they need to conduct tests. Whether a business has an internal security team or relies on outsourced manual pentests, leveraging security automation can significantly reduce costs.

    Businesses with internal security teams can use automation to test builds immediately after devs release code. By continuously assessing code quality from start to finish, security teams can eliminate their testing time and speed up release cycles. Businesses that outsource security testing can use security automation to cut costs by reducing the frequency of full-scope manual pentests. Instead of testing on a biannual or quarterly basis, continuous automation can help reduce the testing frequency to once or twice a year with comparable coverage.

    The most efficient approach possible is the hybrid security automation approach of guided testing that combines daily automated security testing as mobile apps are built with periodic human security analysts for coverage of the parts of the mobile app that automation can’t cover. Guided testing starts below $20,000 per mobile app for unlimited automated security testing integrated into DevSecOps toolchain with four periodic guided tests per year, slashing outsourced quarterly pentesting costs by more than 75%.

    Mobile apps play an important role in helping businesses generate much-needed revenue, but running fast and cutting corners without security built in ultimately places the business and users at risk. So business leaders should take extra steps to keep them secure, and securing mobile apps can be achieved without breaking the bank. By incorporating security automation and innovations like guided testing into the mobile app development process, businesses can maximize the speed of delivery while simultaneously reducing costs and improving quality.

  • Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome this week made available an integration for the continuous integration/continuous delivery (CI/CD) platform from CircleCI that promises to make it simpler to secure mobile applications before they are deployed.

    As a provider of a platform for securing mobile applications running on iOS and Android platforms, Appdome provides a runtime application self-protection (RASP) platform that, among other capabilities, provides code obfuscation, mobile data encryption, jailbreak detection, root detection, man-in-the-middle attack prevention, on-device anti-malware, anti-fraud, anti-cheat and anti-bot capabilities.

    The platform is now integrated with the Circle CI/CD platform via the Orb framework created by CircleCI to simplify integrations with third-party tools.

    Karen Hsu, senior vice president of mobile DevOps and security solutions for Appdome, said the Appdome Build_2Secure Orb for CircleCI is an example of a series of integrations the company plans to make involving DevOps tools and platform that will make it easier to apply DevSecOps best practices to the deployment of mobile applications. That’s critical because it’s not uncommon for teams using different DevOps platforms and tools to be involved in the development of the same application, she noted.

    A recent Appdome survey suggested consumers are about to force the DevSecOps issue for providers of mobile applications regardless of how mature their processes are. A full 94% of respondents said they would promote a brand if the mobile apps protected them versus 68% that said they’d abandon brands that offered no protection.

    Securing mobile applications is especially challenging because once an application is compromised, it’s relatively trivial for cybercriminals to also inject malicious code into other applications running on a mobile device. There are no automated remediation capabilities, so the best defense is to isolate applications in a way that prevents malware from executing in the first place, noted Hsu. At a time when it’s already clear cybercriminals will be using artificial intelligence (AI) platforms to launch attacks, organizations will not have the time required to remediate vulnerabilities before malware is activated, she added.

    That Appdome approach provides the added benefit of reducing tensions between developers and cybersecurity teams that otherwise would be requesting immediate fixes to mobile applications that have been compromised, noted Hsu. As more mobile applications are built and deployed, the overall goal should be to enable both teams to work collaboratively together without unnecessarily disrupting each other’s workflow, added Hsu.

    It’s not clear what percentage of the applications being built and deployed today are destined to run on mobile devices, but securing those applications clearly presents some unique challenges. Many of those applications are deployed on consumer-grade devices attached to wireless networks that are not especially secure. Cybercriminals are increasingly targeting these devices not only to access sensitive data but also because they often provide a gateway through which the rest of an IT environment can be compromised.

    The simple truth of the matter is, sadly, DevOps teams need to assume that most mobile applications are going to be running in the cybersecurity equivalent of a hostile environment where the odds are considerably stacked against them.