devopsy.kinsta.cloud

Category: IT as Code

  • 5 Serverless Challenges of DevOps Teams and How to Overcome Them

    5 Serverless Challenges of DevOps Teams and How to Overcome Them

    Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation of machine resources. The term ‘serverless’ might be somewhat misleading as it doesn’t mean servers are not involved. Instead, it means that developers no longer have to think about servers, even though they’re running on them.

    The idea is to abstract the infrastructure away so that developers can focus solely on the code. Functions, the units of code, are triggered by a variety of events, including HTTP requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (cron jobs), and user sign-ups or in-app activities.

    The Importance of Serverless for DevOps Teams

    Serverless computing brings a paradigm shift in how applications are built, deployed and managed, directly impacting DevOps teams. The core advantage of serverless for these teams is the significant reduction in operational overhead. With serverless, the cloud provider takes responsibility for running the server, ensuring its reliability, and scaling the infrastructure. This frees DevOps teams from the routine tasks of server provisioning, maintenance, and patching, allowing them to focus more on optimizing the application’s code and business logic.

    However, this shift also demands a change in mindset and approach. DevOps teams must adapt to a more granular, event-driven architecture that serverless promotes. They need to design systems thinking about individual functions and how they interact, instead of traditional monolithic applications or even microservices. This requires a deeper understanding of the cloud environment and its services, as serverless functions are often tightly integrated with other cloud services like databases, message queues, and API gateways.

    Moreover, serverless computing introduces new challenges in areas like security, monitoring, and cost management. For instance, the ephemeral nature of serverless functions can make traditional monitoring approaches less effective, and the dynamic scaling can lead to unpredictable costs. DevOps teams need to develop new strategies and adopt specialized tools to address these challenges. Despite these issues, the benefits of serverless – in terms of agility, scalability, and potential cost savings – make it an increasingly essential tool in the DevOps arsenal, particularly for organizations looking to innovate and deploy rapidly in a cloud-centric world.

    5 Serverless Challenges of DevOps Teams and How to Overcome Them

    1. Complexity of Monitoring in Serverless

    A main challenge in the serverless world is the complexity of monitoring. Unlike traditional architectures where you can monitor physical or virtual servers, in serverless, you need to monitor individual functions. This can be tricky as you may have hundreds or even thousands of functions running simultaneously.

    To effectively monitor serverless architectures, you need to go beyond traditional methods. You need tools that can provide insights at the function level, such as AWS CloudWatch or Azure Monitor. These tools allow you to monitor metrics like execution time, error rates, and invocation counts for each of your functions.

    But monitoring is not just about gathering metrics. It’s also about understanding the relationships between your functions and other components of your system. For this, you need distributed tracing tools like AWS X-Ray or OpenTelemetry, which can provide a detailed view of how requests flow through your system.

    2. Managing Lambda Cold Starts

    One of the most common serverless challenges that DevOps teams face is cold starts. A “cold start” refers to the delay that occurs when a function is invoked after being idle for a while. This delay can significantly impact the performance of your applications, especially those that rely on real-time processing.

    The first step to managing Lambda cold starts is understanding what triggers them. Typically, a cold start happens when a new instance of your function is created, which can be due to several reasons, such as an increase in traffic, the deployment of a new version of your function or after a function has been idle for too long.

    To overcome this challenge, there are several strategies you can employ. First, you can use provisioned concurrency, a feature offered by AWS Lambda that allows you to keep a specified number of function instances warm and ready to respond to invocations. Another strategy is to design your applications to be resilient to cold starts by implementing retry logic or using asynchronous invocation when possible.

    3. Security Concerns in Serverless Architectures

    Security is a top concern for any DevOps team. In serverless architectures, you have less control over the underlying infrastructure, making it more difficult to ensure the security of your applications.

    The first step to securing your serverless applications is understanding the shared responsibility model. In a serverless environment, the cloud provider is responsible for securing the infrastructure, while you are responsible for securing your code and configurations. This means you need to pay extra attention to things like input validation, error handling and secure configuration practices.

    Another key aspect of serverless security is managing permissions. Each of your functions should have the least privileges necessary to perform its task. This can be achieved by using identity and access management (IAM) services provided by your cloud provider.

    4. Managing Third-Party Dependencies

    Managing third-party dependencies is another challenge that DevOps teams often face in serverless architectures. These dependencies can introduce vulnerabilities into your applications, affect the performance of your functions, and even increase the cost of your serverless deployments.

    The key to managing third-party dependencies is to minimize their use. Only use dependencies that are necessary for your application and regularly review them to ensure they are still needed. You should also keep your dependencies up-to-date to benefit from the latest security patches and improvements.

    When using third-party dependencies, it’s also important to understand their impact on your functions. You can use tools like AWS X-Ray or Google Cloud Trace to monitor how these dependencies affect the performance of your functions.

    5. Cost Management and Optimization

    While serverless can be cost-effective, it’s easy to rack up high bills if you’re not careful. This is because in serverless, you pay for every invocation of your functions, even if they result in errors.

    To manage costs in serverless, you need to monitor your usage closely. Tools like AWS Cost Explorer or Google Cloud Billing can provide insights into your spending and help you identify areas for optimization.

    You can also optimize costs by designing efficient functions. This means writing code that executes quickly and efficiently, minimizing the use of third-party dependencies, and managing the concurrency of your functions.

    In conclusion, while serverless technologies offer many benefits, they also present unique challenges for DevOps teams. By understanding these challenges and employing the right strategies, you can effectively manage and overcome them, ensuring the successful delivery of your serverless applications.

  • New Relic Adds Ability to Correlate IT Events to Business Processes

    New Relic Adds Ability to Correlate IT Events to Business Processes

    New Relic this week added an ability to enable DevOps teams to better understand the potential business impact any change to an IT environment might have.

    Manav Khurana, chief product officer for New Relic, said New Relic Pathpoint adds a dashboard to the company’s observability platform through which business metrics can be collected alongside telemetry data. That data is collected either via connectors provided by New Relic or via a metrics application programming interface (API) that IT teams can invoke.

    IT teams can use that API to connect to custom applications or an end-to-end business process, noted Khurana.

    All that data is then modeled alongside DevOps telemetry data to provide insights into the impact any change might have on the business in real-time, he added. That approach provides the added benefit of making it easier to strategically align the management of applications, services and infrastructure by business function, noted Khurana.

    In the near future, New Relic will also extend the natural language capabilities it is currently previewing to New Relic Pathpoint, he said.

    Longer term, New Relic is working toward making it possible to model how proposed changes to business processes will impact IT environments, added Khurana.

    Business and IT leaders intuitively understand that every business event creates a corresponding IT event, but most organizations manage those processes in isolation. New Relic Pathpoint presents an opportunity to close a divide between IT teams and the rest of the business that has plagued organizations for decades.

    It may be a while before advances in data analytics and AI eliminate that divide completely, but creating a common set of metrics for managing business and IT processes is a crucial first step.

    In the meantime, DevOps teams, in addition to accelerating the pace at which applications can be built and deployed, are being asked to employ observability platforms such as New Relic One to minimize disruption to the business. Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications using open source agent software, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate IT and business events.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of predefined but often conflicting metrics. Observability platforms, however, unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue, hopefully before any catastrophic disruption can occur.

  • 5 Security Threats DevOps Teams Should Know

    5 Security Threats DevOps Teams Should Know

    DevOps security, also known as DevSecOps, is a philosophy in which security practices are integrated into the DevOps process. DevOps security involves creating a ‘security-as-code’ culture with ongoing, flexible collaboration between release engineers and security teams. The DevSecOps movement, much like DevOps itself, is focused on creating new solutions for complex software development processes within an agile framework.

    DevOps security is about breaking down silos and promoting open collaboration across teams. It’s about making everyone accountable for security with the ultimate aim of improving the quality and speed of code releases. The adoption of a DevOps security model necessitates a cultural shift across the organization. It requires the integration of security into every aspect of the development and operations processes.

    DevOps Security is not just about implementing tools and technologies; it’s about changing the way we look at security. Rather than being an afterthought, security should be a key part of the ongoing conversation from the start of the project to the end.

    5 Security Threats DevOps Teams Must Know About

    As a DevOps professional, it’s crucial to be aware of the potential threats that could compromise your systems, applications, and data. Let’s take a look at the top five security threats that DevOps teams must be aware of.

    Phishing Attacks

    Phishing attacks are a common security threat that can lead to data breaches. These attacks involve cybercriminals impersonating legitimate organizations to trick individuals into revealing sensitive information, such as passwords and credit card numbers.

    Phishing attacks can be particularly damaging for DevOps teams. They can lead to unauthorized access to development systems and data, which can lead to devastating supply chain attacks. For example, an attacker could trick a team member into revealing their login credentials for a critical system, allowing the attacker to gain access and inject malware into a CI/CD pipeline.

    Code Injection

    Code injection is another common security threat that DevOps teams must be aware of. This involves the exploitation of an application by injecting malicious code. The attacker can then execute the malicious code to compromise the system or steal sensitive data.

    For DevOps teams, code injection attacks can be particularly harmful. These attacks can lead to compromised systems and applications, resulting in data breaches and significant downtime.

    Man-in-the-Middle Attacks

    Man-in-the-middle attacks are a type of security threat where the attacker intercepts and potentially alters the communication between two parties without their knowledge. This can lead to a range of damaging outcomes, including data theft, session hijacking, and even identity theft.

    For DevOps teams, man-in-the-middle attacks can be particularly problematic. These attacks can lead to compromised systems and data, and even the unauthorized alteration of code.

    Container Vulnerabilities

    Container vulnerabilities are a significant security threat for DevOps teams. Containers are a key technology in the DevOps world, allowing for the rapid and reliable deployment of applications. However, like any technology, they come with their own set of security risks.

    These vulnerabilities can range from use of insecure images, to misconfigurations and software bugs, to more serious issues like kernel exploits. If an attacker is able to exploit a container vulnerability, they could potentially gain control over the entire system.

    DDoS Attacks

    Last but not least, distributed denial-of-service (DDoS) attacks are a significant security threat that DevOps teams must be aware of. These attacks involve overwhelming a production environment with traffic, causing it to become unavailable to users.

    For DevOps teams, DDoS attacks can be particularly damaging. Not only can they lead to significant downtime, but they can also result in lost revenue and damage to the organization’s reputation.

    How to Mitigate These DevOps Security Threats

    While these security threats are concerning, there are effective strategies and techniques that can be used to mitigate them.

    Implement Email Security Practices and Tools

    To combat phishing attacks, it’s crucial to implement email security tools that can detect and block phishing attempts. These tools can help to filter out phishing emails, reducing the likelihood that team members will fall victim to these attacks.

    In addition to implementing email security, it’s also important to provide security awareness training for team members. This training should cover the basics of cybersecurity, including how to recognize and respond to phishing attempts.

    Use Input Validation and Sanitization in Applications

    To protect against code injection attacks, it’s important to use input validation and sanitization in applications. Input validation involves checking that the data provided by a user meets certain criteria before it’s processed by the application.

    Input sanitization, on the other hand, involves cleaning up the data to remove any potentially harmful elements. This can help to prevent malicious code from being executed within the application.

    Employ HTTPS and SSL/TLS Encryption for Data in Transit

    To guard against man-in-the-middle attacks, it’s important to employ HTTPS and SSL/TLS encryption for data in transit. This ensures that any data being sent between the user and the application is encrypted, making it much more difficult for an attacker to intercept and read the data.

    Regularly Scan Containers for Vulnerabilities

    To protect against container vulnerabilities, it’s crucial to regularly scan containers for vulnerabilities. This involves using tools that can analyze the containers and identify any potential security risks.

    By regularly scanning containers, DevOps teams can identify and address vulnerabilities before they can be exploited by an attacker.

    Implement Rate Limiting and Network Filtering

    Finally, to mitigate the risk of DDoS attacks, it’s important to implement rate limiting and network filtering. Rate limiting involves restricting the number of requests that a user can make to the application within a certain period of time.

    Network filtering, on the other hand, involves blocking traffic from certain IP addresses or ranges that are known to be associated with DDoS attacks. This can help to reduce the impact of a DDoS attack and protect the availability of the application.

    In conclusion, DevOps security is a crucial aspect of the DevOps process. By being aware of potential security threats and taking steps to mitigate them, DevOps teams can significantly reduce the risk of a security breach and ensure the ongoing success of their projects.

  • Survey: Widespread Inability to Remediate App Vulnerabilities

    Survey: Widespread Inability to Remediate App Vulnerabilities

    A survey of 621 IT and security professionals published this week found only 20% are confident in their ability to detect a vulnerability before an application is released.

    Conducted by the Ponemon Institute on behalf of Security Journey, a provider of cybersecurity training services for developers, the survey finds 61% struggling to remediate vulnerabilities effectively, with 55% blaming misalignment between development, security and compliance teams for delays.

    A third of respondents (33%) said teams lacked a common view of applications and assets, with 38% acknowledging they lack the ability to hold departments accountable for patching applications. Only 11% of organizations believed they patch vulnerabilities effectively in a timely manner, the survey finds.

    In the 12 months prior to the study, 54% of respondents suffered a security incident due to an unpatched vulnerability, with 51% experiencing more than eight incidents.

    Overall, half (50%) admitted they fail to test the security of their applications after they have been released. Only 36% specifically teach developers to write secure code. Just one-fifth (21%) educated developers on vulnerability remediation. Less than half (43%) have invested in training provided by a third party.

    When training is provided, 68% of respondents also admitted immediate feedback is not provided and less than half (47%) said secure coding training is customized to meet developer needs. Half (50%) of those who provided training have no formal assessment to measure knowledge gain, the survey found.

    Amy Baker, chief marketing officer and security education evangelist for Security Journey, said the survey makes it clear much work still needs to be done in terms of teaching developers how to write secure code.

    In addition, too many software development teams are overly optimistic about their ability to remediate known vulnerabilities the next time they plan to update an application, said Baker. Many developers move on to the next application simply because either the pressure to meet delivery deadlines is too intense or there is some other emerging technology, such as large language models (LLMs), that needs to be learned, she added. In fact, too many organizations are far too focused on the rate at which applications are built and deployed at the expense of cybersecurity, Baker noted.

    That’s especially problematic because cybercriminals have become much more adept at monitoring application deployments and updates, she added.

    The amount of time between when code is deployed and when cybercriminals begin scanning it for vulnerabilities is now measured in hours rather than days. Developers, unfortunately, are deploying more insecure code than ever. In fact, much of that code is insecure by design, noted Baker.

    Overall, nearly half of respondents (48%) only train developers annually, bi-annually or when an incident occurs. More than two-thirds (68%) only train developers on how to implement secure coding practices to meet compliance requirements. In effect, because developers are not taught security in school, what training they do receive is on the job, said Baker.

    Clearly, there is still much work to be done when it comes to implementing DevSecOps best practices to improve application security. In the meantime, the amount of code that needs to be patched has already reached proportions that most application development teams are never going to be able to effectively address.

  • Venafi Adds Ability to Prevent Unauthorized Code From Running

    Venafi Adds Ability to Prevent Unauthorized Code From Running

    Venafi added an ability to prevent unauthorized code from running in IT environments that make use of its machine identity management platform.

    Shivajee Samdarshi, chief product officer at Venafi, said the Stop Unauthorized Code Solution leverages the company’s CodeSign Protect offering to ensure that only authorized code can run on any given platform.

    The overall goal is to enable organizations to better secure their software supply chains using a zero-trust approach to software based on identity management and code signing to verify software comes from an approved source and complies with policy controls, he added.

    All code is signed using private digital certificates or those issued by trusted certificate authorities, said Samdarshi. Before code can execute, the security platforms an organization has in place can be configured to check that digital signature against trusted code signing certificates, he noted.

    Interest in securing software supply chains has risen sharply since the Biden administration issued an executive order requiring federal agencies to implement a range of measures, including code signing, to achieve that goal. However, securing software chains is often more challenging than organizations initially appreciate.

    In fact, a recent Venafi survey found that 70% of security and IT leaders believe that software supply chain attacks are their biggest security blind spot. Additionally, 85% believe that continuous security validation of the CI/CD pipeline is vital to reduce the risk of vulnerabilities going undetected during the software development lifecycle. A full 88% said they believe machine identity management is essential to the success of zero-trust models that are being more widely adopted across enterprise IT environments.

    Arguably, the most important thing organizations need to focus on is making sure application developers and cybersecurity professionals develop a working relationship. The biggest barrier to the adoption of DevSecOps best practices required to secure software supply chains remains largely cultural. For more years than anyone cares to admit, many developers have viewed cybersecurity more as a hindrance to application development that needs to be overcome or circumvented rather than being a core aspect of a quality assurance process. The total number of vulnerabilities that exist in applications running in production environments could likely be measured in the billions.

    Remediating all those vulnerabilities may never be practical, but at the very least, DevSecOps teams could make sure that no new code containing vulnerabilities is allowed to execute. Cybercriminals have become especially adept at inserting malware into code that they hope will find its way into any number of downstream applications before they activate it. That capability alone should help mollify cybersecurity teams that are increasingly being tasked with improving software supply chain security. The challenge is those cybersecurity teams don’t always appreciate the impact new policies can have on the pace at which applications are developed and deployed.

    Like it or not, software supply chains will generally be more secure in 2024. The only thing that remains to be determined is how much friction will be injected into DevSecOps workflows to achieve that goal.

  • Configuration-as-Code: Trends and Predictions for 2024

    Configuration-as-Code: Trends and Predictions for 2024

    Configuration-as-code, often abbreviated as CaC, is an innovative approach to managing and provisioning computing resources. It refers to the practice of handling changes, deployments and updates to software and systems via code rather than manual processes. CaC allows for a version-controlled, reproducible and automated method of managing environments, leading to more consistent and reliable systems.

    The essence of configuration-as-code is to treat system configurations the same way that software code is treated. This means that configurations are written in a code format, stored in a version control system and applied through automated processes. This approach brings several benefits, including consistency, repeatability and the ability to test changes before applying them to live environments.

    This concept is not just a theoretical approach but rather a practical tool for managing modern digital infrastructure. It’s a key component of DevOps practices, enabling teams to move faster while maintaining control and minimizing the risk of operational issues. Configuration-as-code is a critical tool for managing complex systems and achieving the highest levels of operational efficiency and reliability.

    The Evolution of CaC in Recent Years

    Over the past several years, configuration-as-code has grown from a niche concept into a mainstream practice adopted by many leading technology companies. This evolution has been driven by several factors, including the increasing complexity of digital systems, the rise of cloud computing and the broader adoption of DevOps practices.

    In the early days, system configurations were often managed manually or through ad-hoc scripts. This approach was prone to errors, hard to scale and lacked visibility into changes. As systems grew more complex, the need for a more robust, scalable, and reliable method of managing configurations became apparent. This led to the creation of configuration-as-code.

    The rise of cloud computing has been a significant driver in the adoption of configuration-as-code. With cloud platforms, resources can be provisioned and managed via APIs, making it possible to handle configurations through code. This has allowed for much greater scalability and flexibility enabling companies to manage large, complex environments more effectively.

    The adoption of DevOps practices and increasingly mature automation frameworks have also contributed to the growth of Configuration as Code. As infrastructure-as-code (IaC) becomes the norm, CaC is becoming a staple of modern DevOps practices.

    Trends in Configuration-as-Code for 2024

    Looking ahead to 2024, several trends are likely to shape the future of configuration-as-code:

    Increased Adoption of Cloud-Native Environments

    As more companies adopt cloud-native technologies, the use of configuration-as-code is set to increase. Cloud-native environments are inherently dynamic and complex, making them an ideal fit for configuration-as-code. With CaC, teams can manage these environments more effectively, ensuring consistency, scalability, and reliability. Cloud-native technologies like Kubernetes and Docker also natively support configuration-as-code, making it easier for teams to adopt this approach.

    Use of AI and Machine Learning in Configuration Management

    Artificial intelligence and machine learning are set to play a significant role in the future of configuration management. With AI and ML, teams can automate even more aspects of configuration management, reducing the risk of human errors and freeing up time for more valuable tasks. For example, AI could be used to predict the impact of configuration changes, while machine learning could help automate the process of optimizing configurations for performance and cost efficiency.

    Shift Toward Immutable Infrastructure

    Immutable infrastructure means that servers are never modified after they’re deployed. Instead, any changes are made by deploying a new server with the desired configuration. This approach reduces the risk of configuration drift and ensures a consistent environment. Configuration-as-code is a key enabler of immutable infrastructure, making it easier to manage and deploy servers in a repeatable, automated way.

    Collaboration and Democratization of CaC

    Finally, the trend towards collaboration and democratization in technology will also influence configuration-as-code. With CaC, configurations become more visible and accessible, allowing for greater collaboration between teams. This can lead to better decision-making, less siloed working, and improved overall outcomes. At the same time, configuration-as-code also enables democratization by making it easier for non-technical stakeholders to understand and participate in configuration management.

    Predictions for Configuration-as-Code in 2024

    CaC is Becoming a Cornerstone in the DevSecOps Approach

    The integration of development, security and operations—commonly known as DevSecOps—aims to embed security practices into the DevOps process. As we look towards 2024, configuration-as-code is set to become a cornerstone in the DevSecOps approach.

    By treating infrastructure as code, teams can apply the same security practices they use for application code to their infrastructure. This includes performing code reviews, using automated testing, and tracking changes to the environment. With configuration-as-code, security can shift left—being considered earlier in the development process—leading to more secure systems.

    Moreover, configuration-as-code can help bridge the gap between security and operations teams. It allows for a shared language and shared tools, fostering better collaboration and communication.

    Growth of CaC-as-a-Service

    Configuration-as-code-as-a-service is an emerging trend that is set to grow significantly by 2024. This approach allows businesses to outsource configuration management to a specialist third party, which uses configuration-as-code to automate the process. Cloud-based configuration management solutions provide advanced capabilities such as secrets management, centralized configuration management and orchestrated workflows.

    Version Control Features Specifically Designed for CaC

    Version control systems are a key component of configuration-as-code. They allow teams to track changes to their environment, revert back to previous versions if necessary, and collaborate more effectively. In 2024, we can expect to see the evolution of version control systems with features specifically designed for CaC.

    These features might include support for infrastructure-specific languages and better integration with infrastructure tools. Version control tools might also introduce improved support for collaborative configuration workflows, making it easier for teams to work together on infrastructure configuration.

    Increased Role of CaC in Managing Edge Computing Environments

    As we move into 2024, we can expect to see an increased role for configuration-as-code in managing edge computing environments. Edge computing is rapidly growing due to its ability to bring computation and data storage closer to the location where it is needed, improving response times and saving bandwidth.

    With the rise of edge computing, managing these environments becomes increasingly complex. CaC can automate the process of setting up and maintaining these environments, reducing human error and increasing efficiency. This also allows for consistency across different environments, leading to more reliable systems.

    In conclusion, the future of configuration-as-code looks promising. As we move towards 2024, we can expect to see an increased role for CaC in managing edge computing environments, its evolution as a cornerstone in the DevSecOps approach, the growth of CaC-as-a-Service, and the evolution of version control systems specifically designed for CaC. These developments promise to bring about greater efficiency, security and collaboration in the realm of infrastructure management.

  • Mobb Extends DevSecOps Reach of Tool to Generate Patches

    Mobb Extends DevSecOps Reach of Tool to Generate Patches

    Mobb today added an ability to instantly surface patches for vulnerabilities at the time when code is being committed during a DevSecOps workflow.

    Previously, the tool provided by Mobb to create validated patches based on the scan results of third-party SAST tools would only surface issues to individual developers.

    Mobb CEO Eitan Worcel said organizations can now address these issues within the context of DevSecOps workflow.

    The Mobb platform combines proprietary security research and traditional semantic analysis with generative artificial intelligence (AI) to automatically create patches for vulnerabilities. The overall goal is to make it simpler for DevSecOps teams to consistently ensure applications with known vulnerabilities are remediated before they are deployed, said Worcel.

    The Mobb approach eliminates the need for IT teams to sort through static application security testing (SAST) scans themselves. Each vulnerability typically requires at least 30 minutes to fix, so the Mobb platform improves application security while simultaneously making developers more productive.

    Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool automatically creates the necessary patch, so there is less of a need to debate which vulnerabilities are worthy of the time required to create a patch.

    For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing software supply chains as part of a larger effort to improve application security.

    There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that address common vulnerabilities.

    The process by which patches are prioritized, developed and then applied has, of course, long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities. The challenge is finding a way to remediate vulnerabilities that developers will embrace rather than resist. The Mobb approach still provides them with control over what patches are applied but the toil involved with creating a patch in the first place has been substantially reduced.

    It’s not clear how long it might be before automated approaches to building patches might improve the overall state of application security but, as always, every journey needs to begin with a first step in the right general direction.

  • Legit Security Applies AI to Detect Vulnerable Application Secrets

    Legit Security Applies AI to Detect Vulnerable Application Secrets

    Legit Security today announced it has expanded the scope of its application security posture management (ASPM) platform to make use of artificial intelligence (AI) to discover secrets more accurately in applications that cybercriminals can actually exploit.

    Scanners typically generate high false positive rates to the point where developers often start to ignore them. As a result, it’s not uncommon for secrets to be discovered in an application even though an alert was generated.

    Legit Security CTO Liav Caspi said the company is now applying a large language model (LLM) specifically trained for source code along with prompt engineering techniques and heuristics to reduce the level of alert noise that developers would otherwise see when scanning for secrets. The overall goal is to correctly identify access keys, passwords, application programming interface (API) keys and other personally identifiable information (PII) that should not be exposed once an application is deployed in a production environment, he noted.

    That capability can be applied to detect secrets across all development assets, including code repositories, source code management (SCM) tools, build tools and logs, artifacts and private and public documentation. In addition, this approach also uncovers toxic combinations of secrets or ones that might lie buried within assets such as source code history or modified Confluence pages that developers often forget exist, noted Caspi.

    Legit Security also enables DevSecOps teams to apply preventive guardrails on developer endpoints using the Legit command line interface (CLI) to stop secrets from being exposed before code is pushed. In addition, automated workflows can reach developers as part of a pull request or create Slack messages or Jira tickets to streamline remediation. DevSecOps teams can also continuously triage results to create a baseline that includes exceptions.

    As part of a larger effort to secure software supply chains, Legit Security has developed a software-as-a-service (SaaS) platform designed to apply security policies across an entire software development life cycle. The company is now extending the capabilities of that platform using AI technologies to detect secrets in both source code and all the components that make up a development pipeline as they are added.

    In the wake of an executive order requiring federal agencies to better secure software supply chains, there is now more focus than ever on application security. Unfortunately, many developers are a little too cavalier when it comes to managing secrets during the application development process. They often leave secrets in plain text to facilitate workflows, but more often than many care to admit, those secrets are not removed before an application is deployed. Knowing this, cybercriminals have learned to scan applications for those exposed secrets. Once gained, they then appear to be just another legitimate user of an application that might not be discovered until malware is activated.

    It may be a while before the cultural and technical issues that conspire to make the software supply chain insecure are fully addressed. In fact, the problem may get worse before it gets better—simply because the pace at which distributed applications are being built and deployed only continues to accelerate. At the same, the cost of making a secrets mistake is also only going to increase as regulations become more stringent. In fact, it’s now only a matter of time before stiff fines intended to make an example of one or more unfortunate organizations are eventually going to be levied.

  • How Network APIs Will Finally Realize the Potential of 5G Slicing

    How Network APIs Will Finally Realize the Potential of 5G Slicing

    The applications used by people and businesses today run over the top of the network. That is, they use the network to transmit data from one point to another but don’t interact with the network in any way.

    As those applications get more advanced, that comes with a risk. If the network isn’t provisioned adequately, a self-driving car, for instance, might suddenly lose connectivity and freeze in the middle of an intersection.

    That’s why developers are progressively realizing they’re going to require more from the network if they are to create revolutionary new applications. But the catch is they’re also not network specialists.

    Instead, they yearn for quick and simple ways to tap into and onboard 5G network capabilities within their applications — to dynamically adjust connectivity speeds based on real-time conditions, for example. That’s where network application programming interfaces (APIs) enter the picture.

    In 2023, the telecoms industry committed to unprecedented levels of openness with the announcement of the GSMA Open Gateway initiative and the growing popularity of the CAMARA project.

    In 2024, there is an expectation that there could be even more momentum around and demand for open network APIs as developers start to get real access to them — and begin to explore the potential of leveraging specialized network capabilities, delivered through techniques such as network slicing for their enterprise and consumer applications.

    What are Network APIs and How Will They Be Used?

    A network API is like any other API that allows for two or more applications to communicate with each other. It’s just that, in this case, one of those applications is the network itself.

    This is possible because today’s cloud-native 5G networks are fundamentally software-based, meaning they are also programmable through APIs and other software development tools. So unlike the networks of years ago, which were more hardware-dependent and closed in nature, developers can now get easy access to deep functionality and data within the network.

    Through a network API, applications and networks can share information about their status and needs, allowing for optimizations to be made on either side. The network could signal to a drone or autonomous vehicle where other related devices are operating or whether congestion is likely to occur in a given area, enabling on-the-fly route changes to maintain optimal performance. Or the application could use that information to request specialized capabilities from the network in certain situations, such as low-latency connectivity or more uplink capacity.

    The ability to deploy specialized network capabilities for specific applications in specific locations may sound familiar. It’s essentially the promise of network slicing, which was promoted heavily in the early days of 5G rollouts but never really caught on as expected.

    This is largely because network slices have to be planned for and provisioned well in advance — a dealbreaker for applications that need to manipulate parameters such as quality of service based on real-time conditions.

    Network APIs change that, providing access to specialized network capabilities in a dynamic, automated way — whether by spinning up a network slice or through the use of other telecommunications tools. The emerging applications of tomorrow will increasingly require such specialized network capabilities.

    Consider beyond visual line of sight (BVLS) drones that are operated remotely by a person hundreds of kilometers away. As the drone travels, it will need different network capabilities at different parts of the journey based on the unique conditions it encounters along the way.

    Deutsche Telekom has been working to deploy network APIs for this very scenario, which includes APIs for location verification (for more precise tracking of the drone’s position) as well as “quality on demand,” so that as it passes over highly congested areas where thousands of people are also using up network capacity, the drone can get greater prioritization to ensure it doesn’t fall out of the sky.

    That’s just one potential use case. Network APIs can open up innovations for industrial robots, real-time streaming of immersive video using multiple cameras, latency-sensitive applications like VR and cloud gaming, and much more.

    Creating a Network-Powered System Ecosystem

    APIs can help foster a network-powered ecosystem of digital innovation that brings benefits to everybody involved. By being able to leverage specialized network capabilities on demand, developers can create innovative applications and experiences for their customers — transforming their ideas into real solutions.

    Existing applications can also be enhanced for better performance, such as drones that can reliably transmit high-definition video from any location and under any circumstances to improve the situational awareness of first responders and public safety agencies.

    For the communication service providers (CSPs) who operate the networks, these APIs will help deliver a better return on investment for their 5G infrastructure. Revenue growth for traditional communications services in both the consumer and enterprise markets is limited by an unwillingness to pay more for those services and the perception that value lies in the applications rather than the network.

    Thus, the need for CSPs to develop new revenue streams has never been greater. By charging developers for access to the network APIs — and by forging closer connections to the applications that will use the capabilities within the network — CSPs will be better able to generate monetizable value from their networks.

    What’s Ahead for Network APIs

    APIs have been around for more than two decades. The fundamental principles of network slicing have been talked about since the introduction of 4G. While these technologies have been around for years, they will come together in exciting new ways in 2024, enabling entirely new possibilities.

    In the year ahead, there will likely be a greater demand for specialized network capabilities among application developers. That demand will be driven by early digital adopters in industries such as oil and gas, automotive, industrial and high-tech manufacturing, public safety, security, gaming and entertainment, and others.

    But it’s important to note that no one company can make all this work. There needs an ecosystem of companies coming together. Developers need to demand it, and CSPs need to build systems and platforms to support it.

    Infrastructure vendors will play a role as well, with network as code platforms to provide easy access to network APIs — serving as the bridge that enables greater levels of collaboration, innovation and mutual growth so everybody can harness the full potential of 5G networks.