devopsy.kinsta.cloud

Tag: application security

No Country for No-Code: Are We Heading Towards a Wild West of Software Security?

Nearly everything we use is built on code, from cars to smart fridges to doorbells. In businesses, countless applications keep devices, workflows and operations running. So, when early no-code development platforms launched in 2010, promising more accessible application development for citizen developers, its success felt inevitable.

It’s hard to deny the success of no-code. These platforms flatten the learning curve for would-be developers, allowing organizations to innovate and automate with useful applications despite a developer skills shortage. Plus, the out-of-the-box applications offered by no-code platforms expedite the application development process in a world where speed-to-market is king. Last year, Forrester found that 87% of enterprise developers use low-code and no-code tools or platforms for at least some of their workload.

But functionality is not the only sign of success. Unintentionally, the same trends that pushed for application development to be democratized have led to a wild west of insecure applications and misconfigurations that expose a whole host of organizations to cyberthreats.

The Importance of Security

While these platforms democratize development, they must be used with caution. The OWASP Top 10 highlights factors such as misconfiguration and using vulnerable components as common security threats. Yet, a reliance on no-code development could introduce un-spotted vulnerabilities directly into an organization.

Forrester has long warned of the risk of no- and low-code, featuring the vulnerability in its predictions for the coming years. The spectrer of an untrained employee creating applications is especially alarming: These platforms empower employees with no application security knowledge to develop programs that security teams are often unaware of.

Organizations must gain real oversight into who is responsible for developing software, whether professional developers leveraging no-code platforms as tools, or citizen developers creating applications for smaller teams and projects. It is no secret that CVEs are rising sharply. They hit a record 28,092 last year and are projected to increase by 25% throughout 2024. Last December, Microsoft revealed a high-severity CVE that affected low-code and no-code users.

When businesses are facing a tide of new exploits each day, skills such as vulnerability detection and remediation are critical to any new software development project.

Software development needs to become more flexible in its roles, but never at the expense of security. By fostering a culture of “security by design” across the organization, security leaders can ensure that all roles in the software development lifecycle (SDLC) understand their responsibilities in their security posture — including citizen developers.

Empowering Human Intervention

Just one in five organizations are confident in their ability to detect a vulnerability before an application is released, according to Security Journey research, meaning that the security knowledge in most SLDCs is insufficient. Developers need to be trained to create secure software and to sniff out insecure code in the rest of the code base – responding and fixing it quickly – before it gets to production. Without this, application security and security teams are left with an unnecessary burden, which ultimately requires more time, expense, and potential for business risk. Securing vulnerabilities after the fact, through regular security scanning and patching, should not be the norm.

Instead, organizations have an opportunity to empower developers with security skills and knowledge throughout their careers. These skills allow them to deliver a higher quality of output and play a vital role in securing the organization itself. And yet, just one in three organizations (36%) train developers to write secure code, which ensures that software security starts at the end of the development process 64% of the time. The same goes for citizen developers, whose work often shows a passion for problem-solving and innovation that should be harnessed and supported with the right training.

A Problem for the Future

It would be reductive to suggest that software security risk is rising purely because of no-code and low-code platforms, or even that citizen developers are a majority contributor to CVEs. The very culture of software development has been forcing the industry down a path of speed and ease over security for almost two decades. The surge in AI-generated coding proves this more than anything.

So long as developers and the project managers above them are incentivized to move fast, each new solution will be valued based on its ability to create functional code quickly. This will be the case until security is made a priority by regulators and, importantly, by executives and the board.

The cultural disconnection at the heart of the software security crisis is human-made. No matter which tool is in the spotlight, building secure software will require human solutions. While large language models (LLMs) aren’t yet equipped to tackle the complex considerations that developers face daily, the biggest risk will come from complacency, overreliance and blind trust from their users. Human developers, equipped to perform rigorous code reviews and remediate any vulnerabilities they find, are central to the safe implementation of any of these technologies, whether no-code, low-code or AI-generated. Without this, the tools run the risk of introducing more vulnerabilities with less critical supervision.

No matter what tools arise, knowledgeable human users will always need to understand what the tool is providing and can act as a stopgap for quality and security.

May 14, 2024
JFrog Survey Surfaces Raft of DevSecOps Challenges

A global survey of 1,224 security, development, and IT operations professionals published today by JFrog finds that 60% typically spend four days or more remediating application vulnerabilities in a given month.

JFrog security researchers, however, noted it’s probable most of those vulnerabilities are not as severe as they have been rated. After analyzing 212 vulnerabilities, the JFrog Security Research team downgraded the severity of 85% of the vulnerabilities rated as critical and 73% of one rated as high.

JFrog researchers also found that 74% of the reported common vulnerabilities and exposure (CVEs) with high and critical CVSS scores assigned to the top 100 Docker Hub community images weren’t actually exploitable.

Only 17% of the vulnerabilities analyzed enabled remote code execution, compared to 44% that could enable a denial of service (DoS) attack, the researchers noted.

Stephen Chin, senior director for developer relations for JFrog, said that analysis suggests organizations are arguably spending too much time on application security at the expense of productivity. Tools that generate alerts based on severity rather than also rating exploitability are creating too much noise simply because they don’t provide enough contextual analysis, he added.

Conversely, in the absence of that level of detailed analysis, it’s possible a low-level vulnerability that might be especially severe in a specific IT environment, also known as a false negative, might not be further investigated, noted Chin.

Security concerns, however, also limit innovation, with 40% of the survey respondents noting that because of security reviews, it typically takes a week or longer to get approval to use a new package/library.

Nearly half of IT professionals (47%) say they use between four and nine application security tools, with 90% reporting they use some type of tools that rely on machine learning algorithms or other forms of artificial intelligence (AI) to scan, identify and remediate vulnerabilities.

Less than a third (32%), however, work for organizations that use AI to write code. That relatively low level suggests many organizations are still not comfortable with the quality of the code generated, noted Chin. Of course, individual developers may still be using those tools without approval.

More than half (53%) say their organization uses between four to nine programming languages, with nearly a third (31%) reporting they use 10 or more.

The most frequently used tools are static application security testing (61%), dynamic application security testing (58%), software composition analysis testing (56%), and application programming interface (API) security (56%).

A full 89% said their organization has adopted a security framework such as OpenSSF or Supply-chain Levels for Software Artifacts (SLSA).

Finally, the survey finds little consensus concerning when to run security scans, with 42% saying it’s best to perform security scans as code is being written versus 41% that prefer to perform scans on new software packages before installing them. A total of 41% said runtime is the least desirable place to run scans. More than half (56%) said their organization applies security scans at both the code and binary scanning levels.

The degree to which DevSecOps best practices are being adopted will naturally vary from one organization to the next. The challenge is to prioritize remediation efforts in a way that enables developers to spend more time writing, for example, business logic versus patching vulnerabilities are not actually a material threat. In that context, the quality of the vulnerability analysis generated by scanning tools matters because of the unnecessary toil that might be eliminated, noted Chin.

It may be a while before most organizations are able to strike the right balance when it comes to DevSecOps, but as a greater appreciation for the nuances of application security continues to take hold, the less stress there should hopefully one day be for all concerned.

March 19, 2024
Cycode Acquires Bearer to Extend ASPM Platform

Cycode today announced it had acquired Bearer, a provider of a set of tools for static application security testing (SAST), discovering application programming interfaces (APIs) and identifying sensitive data.

The provider of an application security posture management platform (ASPM) plans to integrate the Bearer tools into its core platform to enable DevSecOps teams to further consolidate tooling.

Cycode CEO Lior Levy said the acquisition of Bearer gives Cycode access to a set of tools that take advantage of generative artificial intelligence (AI) to surface suggestions that enable DevSecOps teams to more easily secure modern applications based on, for example, a microservices-based architecture.

Bearer achieves that goal by continuously scanning for application security issues as developers are writing code, he added. Overall, Bearer claims its approach to scanning is 31% faster than rival tools while simultaneously leveraging tools such as Bearer Assist, currently in beta, to provide more context concerning the level of risk to the business any issue discovered actually represents.

Those capabilities will be infused into the Risk Intelligence Graph (RIG) that Cycode developed for its ASPM platform.

Cycode earlier this year added generative AI capabilities to its platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments. The company uses the generative AI platform created by OpenAI to provide a natural language interface for RIG. As part of that effort, Cycode is making available an executive dashboard that, based on all the dependencies uncovered, provides summaries of risks that make it easier to discern what is occurring across an application environment.

The company is at the forefront of developing ASPM platforms that continuously ingest data to identify and assess application security risks. Those platforms also provide a foundation for consolidating many of the tools that DevSecOps teams currently rely on to secure applications before they are deployed in production environments.

It’s not clear how quickly organizations are embracing DevSecOps best practices, but given the number of vulnerabilities that continue to be discovered, there is still much work to be done. The challenge is that legacy tools that lack AI capabilities were not designed to enable organizations to practically shift more responsibility left toward application development teams that typically don’t have a lot of cybersecurity expertise, noted Levy. AI makes it possible to now provide those teams with the context required to address application security issues as they write code versus just before applications are deployed, he added.

In theory at least, the applications deployed today should be significantly more secure than previous generations of applications. In effect, IT environments are steadily becoming more secure. Less apparent, however, is the rate at which modern applications are being deployed to replace legacy applications that are, all too often, rife with known vulnerabilities that cybercriminals can easily exploit. Given the rate at which vulnerabilities can be discovered and patched in those legacy applications, it may take the better part of the rest of this decade to address those issues once and for all.

March 5, 2024
Cycode Brings Generative AI to App Security Posture Management

Cycode today added generative artificial intelligence (AI) capabilities to its application security posture management (ASPM) platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments.

At the same time, Cycode is adding plugins for VS Code and JetBrains integrated development environments, a command line interface and pull request scanners to make it easier to identify security issues as early as possible during the software development life cycle (SDLC). Cycode also revealed today it now has more than 75 connectors to various security tools commonly used within DevSecOps workflows.

Amir Kazemi, director of product marketing for Cycode, said the company is using OpenAI’s generative AI platform to provide a natural language interface for invoking the Risk Intelligence Graph that is at the core of the Cycode ASPM platform. As part of that effort, Cycode is now also making available an Executive Dashboard that, based on all the dependencies uncovered, provides summaries of risks that make it easier to discern what is occurring across an application environment.

The platform, as a result, can now provide automated risk scoring for vulnerabilities based on actual severity and potential impact to the business, said Kazemi. The overall goal is to make it simpler to secure software supply chains by facilitating the proactive collaboration between application developers, DevOps engineers and cybersecurity professionals, he added.

It’s not clear what impact generative AI is going to have on how DevSecOps workflows are constructed, but making it easier to identify the root cause of security issues in application environments made up of monolithic applications, microservices and event-driven frameworks is now essential. Application security has simply become too chaotic to effectively manage without help from AI, noted Kazemi. In its current state, application security is simply unmanageable, he added.

The challenge is that just because a zero-day vulnerability has been discovered, it doesn’t always follow that application development teams know where every instance of it exists within their application environment. It’s not uncommon for DevSecOps teams to discover outdated versions of components that have known vulnerabilities to be running months after a patch in an updated version of that component has been made available.

DevSecOps teams are, of course, always trying to strike a balance between the level of threat a vulnerability represents and the possibility that the patch that should be applied might break an application. However, given the risk to application environments, it’s becoming less risky to patch an application than it is to hope that cybercriminals don’t exploit a known vulnerability.

While much DevSecOps progress has been made in recent years, it’s clear there is still much work to be done. Hopefully, generative AI will make it simpler for application development teams to address issues more rapidly than ever. In the meantime, however, DevSecOps teams should assume cybercriminals are looking to exploit the same AI capabilities to discover vulnerabilities they can exploit faster than ever.

February 21, 2024
Veracode Report Shines Spotlight on Massive Application Security Debt

An analysis of more than a million applications published today by Veracode, a provider of a software supply chain security platform, found 42% of applications contained flaws that remained unfixed for longer than a year.

Based on 1,553,022 dynamic analysis scans and 11,429,365 static analysis scans, the report noted that those applications with that level of security debt were found in 71% of the organizations maintaining these applications. Nealy half of organizations (46%) have persistent, high-severity flaws that constitute ‘critical’ security debt. Approximately 63% of applications have flaws in first-party code, while 70% contain flaws in third-party code imported via third-party libraries.

Remediation rates also vary by flaw type. Fixing third-party flaws takes 50% longer, with half the known flaws fixed after 11 months, compared to seven months for first-party flaws.

Collectively, the scan run by Veracode produced 96 million raw static findings, four million raw dynamic findings and 12.2 million raw software composition analysis findings.

Chris Eng, chief research officer for Veracode, said it’s clear too many organizations are kicking application security flaws down the road only to find they don’t have the time to address them properly. Meanwhile, cybercriminal syndicates and nation-states are becoming more adept at exploiting these flaws with each passing day, he added.

In general, there is a lot more focus on software supply chain security in the wake of an executive order issued by the Biden administration that requires federal agencies to identify and remediate security flaws. However, the pace at which enterprise IT organizations are following the lead of the Federal government varies widely. Only a relatively small percentage of the vulnerabilities that exist in applications running in production environments are being exploited, so many enterprise IT teams have yet to prioritize the issue.

However, as more cybercriminals acquire the skills required to discover and exploit those vulnerabilities, it’s only a matter of time before a major application security crisis ensues, noted Eng.

Theoretically, at least, artificial intelligence (AI) should one day soon make it easier to discover and remediate vulnerabilities, but it’s just as likely cybercriminals will use the same capabilities to achieve their own nefarious ends. In fact, it’s largely a race against time before existing application flaws are exploited using AI-based tools and techniques. Application development teams that fix flaws the fastest reduce critical security debt by 75%, from 22% of applications to just over 5%, the Veracode report noted.

Naturally, it’s less costly and simpler to fix security flaws before applications are deployed in a production environment, so the more organizations embrace DevSecOps best practices on the front end, the lower the overall security debt becomes, noted Eng.

It’s not clear whether organizations might decide to replace or consolidate applications to reduce their security debt, but given the overall lack of cybersecurity expertise among application developers, the current level of security debt is likely to continue to rise. The challenge, of course, is that as the security debt rises, the number of developers available to address, unfortunately, remains comparatively constant.

February 14, 2024
GitGuardian Allies With CyberArk to Better Protect App Secrets

GitGuardian this week revealed it has allied with CyberArk to streamline secrets detection and management by making it easier to share insights.

Ziad Ghalleb, product marketing manager for GitGuardian, said the two companies have integrated their respective platforms using open source software that integrates GitGuardian Secrets Detection and CyberArk Conjur Cloud, a software-as-a-service (SaaS) platform for managing and rotating secrets as needed.

In addition, CyberArk Conjur Cloud is now integrated with HasMySecretLeaked, a tool for discovering if a specific secret has been exposed on GitHub. That capability enables DevSecOps teams to periodically cross-reference secrets and credentials against a private database of secrets known to have been publicly exposed.

GitGuardian claims to have uncovered more than 20 million publicly exposed secrets on the GitHub repository. While GitGuardian provides tools to discover exposed secrets, organizations rely on the CyberArk platform to manage secrets and remediate issues that arise when they are left exposed.

The immediate challenge is to find ways to integrate secrets detection within the context of larger ecosystems, said Ghalleb. In the longer term, GitGuardian is working toward embedding its tool into integrated development environments (IDEs) to surface exposed secrets as developers build software, said Ghalleb.

Naturally, there is a lot more focus on secret detection, and secrets management is getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. For many organizations, however, it’s still early days as far as adopting DevSecOps best practices to secure those software supply chains, but it’s clear more responsibility for application security is shifting left toward developers and the DevOps teams that support them.

Unfortunately, too many developers still hard-code secrets in plain text into applications to create shortcuts as software is developed. Many forget to remove those secrets before an application is deployed in a production environment. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all.

In the meantime, cybercriminals are becoming more adept at using scanning tools to discover secrets and then exploiting them to compromise applications after they have been deployed.

Hopefully, DevOps teams will implement DevSecOps best practices to address those issues before any fines are levied. But the challenge, as always, is ensuring application security without adversely impacting the rate at which software is currently being built.

It’s only a matter of time before more stringent regulations require organizations to revisit the security of software supply chains. Countries around the world are drafting legislation that would hold organizations much more accountable for the security of the applications they build and deploy. As more fines are eventually levied, the tolerance for leaving secrets exposed in applications is only going to decline.

Secrets discovery and management is, of course, only one aspect of application security, but the more these issues are addressed before applications are deployed the less stressful cybersecurity becomes.

February 9, 2024
Graylog Makes Free API Security Tool Available to Developers

Graylog this week made available a free version of its platform for securing application programming interfaces (APIs), intended to encourage developers to adopt best practices to secure them.

The free version of Graylog API Security has all the capabilities of the paid version but is limited to 16GB of local rolling storage on a single node with a one-year renewable license.

Graylog CEO Andy Grolnick said the goal is to make it simple for developers to use this edition of the platform as they are building APIs. As applications are deployed in a production environment, the expectation is organizations will then need to access the version of the platform that is designed to scale, he added.

Based on technology Graylog gained with the acquisition of an API security platform originally developed by Resurface.io, this free version of Graylog’s API security platform is trying to help bridge the divide between the application development teams that create APIs and the cybersecurity teams tasked with protecting them, said Grolnick.

Capabilities of the platform include API classification, discovery, risk scoring, an ability to capture API request and response payloads and continuous monitoring of API and threat signatures in real-time. Collectively, these capabilities enable Graylog API Security to provide high-fidelity alerts using a data lake that is embedded in the platform, noted Grolnick.

That approach enables Graylog API Security to capture all API requests and response details to distinguish valid API traffic from malicious activity involving, for example, data exfiltration hiding under valid response codes.

In addition, Graylog API Security automatically surfaces remediation guidance for developers who typically lack cybersecurity expertise.

API security has become a major DevSecOps issue because cybercriminals are increasingly targeting APIs to steal data. As more externally facing APIs are deployed, the overall size of the attack surface that needs to be defended increases exponentially.

A recent survey conducted by Enterprise Strategy Group (ESG) on behalf of Graylog found more than three-quarters of respondents (76%) have an average of 26 APIs per application. Most respondents are using open APIs for public consumption (67%) or are connecting applications with partners (64%).

In general, most of those APIs are internally facing, but it’s not uncommon for those APIs to suddenly be exposed to the internet as use cases for applications evolve. The challenge is that few cybersecurity teams have visibility into APIs that, when manipulated by malicious actors, can expose code or provide a mechanism through which business processes can be compromised. This issue often exists because, in many organizations, it’s still not clear who is actually responsible for API security.

Arguably, the best way to ensure API security is at the point of creation. Providing developers with API security tools gives them a chance to do the right thing from the beginning of the application development process, said Grolnick.

There have already been several cybersecurity breaches involving APIs in the past year. It may only be a matter of time before there are additional breaches that could prove catastrophic. Regardless of the size of the API breach, the application development team that created and deployed the API in the first place is ultimately going to be held accountable for fixing it.

February 2, 2024
Snyk Acquires Helios to Extend Reach of ASPM Platform

With its acquisition of Helios, Snyk plans to add an ability to capture application runtime data to extend the capabilities of its application security posture management (ASPM) platform.

Manoj Nair, chief product officer for Snyk, said Snyk AppRisk will soon provide real-time insights into runtime environments using a Helios observability platform that provides them with deeper insights into issues that need to be resolved. That capability will provide developers with additional context as more responsibility for application security continues to shift left toward application development teams, he added.

Armed with that insight, it then becomes simpler to prioritize remediation efforts based on the level of risk a vulnerability actually represents to the organization, said Nair. That’s critical to close a longstanding divide between cybersecurity and application development teams that, in the absence of any real ability to determine the severity of a vulnerability, results in developers wasting what limited time they have to allocate to remediation, he noted.

Nair said the overall goal is to enable organizations to deploy more secure applications while minimizing adverse impacts on developer productivity.

Snyk last year acquired Enso Security to add an ASPM platform to its portfolio that serves as the foundation upon which Snyk AppRisk was built. It also includes Insights, a Snyk tool that makes use of multiple types of artificial intelligence (AI) models to identify, prioritize and fix vulnerabilities.

There’s often not a lot of love lost between cybersecurity teams and application developers who typically don’t have a lot of cybersecurity expertise. Most of the issues that cybersecurity teams are tasked to address start with mistakes made by developers that cybersecurity teams then need to convince developers to allocate time to fix.

Thanks to the rise of DevSecOps best practices, the overall security of software supply chains is improving, but there is still a long way to go before application security truly improves. The one thing that is certain is the level of accountability for vulnerabilities is only going to rise as more stringent regulations go into effect in the months and years ahead.

In the meantime, DevSecOps teams should assume there will be many more vulnerabilities to remediate. Developers are increasingly using generative AI tools to write code. The challenge is general-purpose large language models (LLMs), such as the one used to drive ChatGPT, were trained using examples of code of varying quality collected from across the web. A lot of the code these platforms generate, not surprisingly, contains vulnerabilities that many developers will not immediately recognize without the aid of some type of scanning tool.

At the same time, cybercriminals are becoming more efficient at discovering and exploiting vulnerabilities that exist in applications that have already been deployed in production environments. DevSecOps teams should expect that, as a result, more zero-day vulnerabilities requiring immediate attention will soon be discovered.

One way or another, the percentage of time allocated to application security issues is only going to increase. The only thing left to determine is how best to go about reducing the time and effort needed to make applications as secure as possible.

January 29, 2024
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.

January 25, 2024
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.

January 24, 2024