devopsy.kinsta.cloud

Category: IT Security

CISA Pushes Steps to Better Secure Software and Product Designs

The country’s top cybersecurity agency is urging developers to take steps to ensure the software they’re building and the products they roll out are secure and protect end users.

The Cybersecurity and Infrastructure Security Agency (CISA) this week rolled out a series of recommendations that it wants businesses and critical infrastructure organizations to adopt to protect themselves against the growing cyberthreats they face.

The 18 “voluntary practices with high-impact security actions” – divided between recommendations for software development processes and product design – are part of a larger push by CISA over the past few years to secure the software supply chain and to shift the responsibility of security from the users of products to the organizations that create them.

They dovetail with the agency’s secure-by-design efforts, which advocate for address security throughout the software development lifecycle. They also reflect the Secure Software Development Framework developed by the National Institute of Standards and Technology (NIST), according to Chris Hughes, chief security advisor at software supply chain security firm Endor Labs and a CISA Cyber Innovation Fellow.

“They’re good reminders and solid cyber hygiene recommendations that most organizations should be doing, especially those in IT- and product-centric development environments, with ramifications for downstream customers and consumers,” Hughes said.

MFA, SBOMs and More

None of the recommendations should come as a surprise to developers. Regarding software development, CISA recommends developers separate all the environments in the process, such as development, build, test, and distribution, enforce multifactor authentication (MFA) across all of them, eliminate the use of insecure storage and transmission of plaintext credentials, used automated tools to test software for vulnerabilities and deal with security flaws before releasing the software.

In addition, the agency wants organizations to make software bills-of-material (SBOMs) – a key security step that CISA has been advocating for to detail all the components used to create the product – available to customers.

For product design, key steps include broader use of MFA for customers, eliminating default passwords, releasing security patches broadly and promptly, and enabling users to understand, monitor, and respond to cybersecurity issues affecting products, such as initial access, privilege escalation and lateral movement.

Businesses also need to be clear with users when products are reaching end-of-life and security patches will no longer be available for them.

A Good Start

While applauding CISA’s efforts, Hughes said there are other areas that should have been emphasized more.

“There is some language around vulnerabilities,” he said. “It could be taken a step further with an emphasis on prioritizing known exploitation, exploitation probability, and reachability for not just internal vulnerability management efforts but in external communications through vulnerability disclosures, for example.”

Other areas of emphasis could have been open-source software governance and security and broader specifications for cybersecurity supply chain risk management (C-SCRM) for third parties, including software-as-a-service (SaaS) providers.

What About C-SCRM?

Supply chain risk management is a fast-growing market, with Introspective Market Research analysts expecting the space to expand from $3.46 billion in 2023 to $7.68 billion by 2032. C-SCRM is a more specific area of the market that focuses on identifying, analyzing, and mitigating vulnerabilities, data exposures, and similar security issues in IT and operational technology products and services. It’s a process pushed by NIST, the General Services Administration (GSA), and other government agencies.

What will be most challenging is that these steps are voluntary, Hughes said, adding that they “will conflict with competing priorities organizations have, such as speed to market, revenue, feature velocity and market share, all of which CISA has themselves cited as challenges with efforts such as Secure-by-Design.”

It’s also unclear how CISA’s mandate will change under the incoming presidential administration, which has long been an opponent of regulations on the private sector and is expected to narrow the agency’s responsibilities.

January 10, 2025
White House to Spend $11 Million to Study Open Source Software Use

Hardening the security around open source software has been a key part of the White House’s larger cybersecurity efforts since President Biden released his executive order for improving the United States’ security posture in May 2021, only months after taking office.

Now the Biden Administration and the Department of Homeland Security (DHS) are putting $11 million to launch a program aimed at assessing the use of open source software in critical infrastructure environments and how to better protect it.

Speaking at the Def-Con show late last week in Las Vegas, National Cyber Director Harry Coker Jr. announced the plan to launch the government’s Open Source Software Prevalence Initiative, which includes participation by the country’s National Laboratories.

“We know that open-source underlies our digital infrastructure, and it’s vital that, as a government, we contribute back to the community as part of our broader infrastructure efforts,” Coker said at the conference.

He added that while the government is creating the initiative and putting money behind it, it will need the participation of cybersecurity professionals.

“These policy proposals rely on the dedication of researchers and their willingness to freely share their findings in order to work,” Coker said. “In our conversations on developing a software liability regime, too, we are increasingly aiming to leverage this unique community as part of novel policy solutions.”

A key part of the Biden Administration’s cybersecurity push to improve the country’s cybersecurity is to shift the responsibility away from technology’s users and toward its creators through such efforts as its Secure By Design software message. Coker reiterated that during his talk, telling the audience of cybersecurity experts of the need for “more of the responsibility for cybersecurity to fall upon the more capable actors in the ecosystem. That means technology producers, yes, and certainly the Federal Government. But it also means all of you.… I know that the same value set that drives responsible vulnerability disclosure will lead you to continue to step up for the protection of the internet.”

Collaboration is Key

The government’s reach is only so long, he said. The president can’t solve problems by simply issuing an order. Coker noted that the government and tech industry has known for decades about security flaws in the Border Gateway Protocol, yet still much of the U.S. internet traffic is vulnerable to being hijacked. The same goes for using memory-safe programming languages like Rust and Go to eliminate a large percentage of vulnerabilities found in today’s software.

“Still, critical software that underlies our society is written in C, simply because that’s what’s convenient,” he said. “The ‘tragedy of the commons’ around open-source software development is a well-understood phenomenon; still, vital packages are maintained by tiny bands of volunteers operating on a less-than shoestring budget.”

Wait and See

Katie Teitler-Santullo, cybersecurity strategist with OX Security, said how effective a program like the Open Source Software Prevalence Initiative can be is uncertain.

“On the one hand, initiatives like this coming down from the White House and DHS signal to private industry that increased scrutiny is coming,” said Teitler-Santullo, whose company offers an application security posture management platform. “Given the growing reliance on open-source software – and the open-source components in most software – businesses must have a better understanding of the software, at all stages of its lifecycle.”

Still, government programs like this don’t come with feasibility or impact guarantees. A lot of organizations have trouble monitoring and triaging what she called the “long tail of software” and app security and development teams have trouble keeping pace with the rapid evolution of the open source ecosystem.

“What’s not in question is the importance of organizations, public and private, to understand and act on open source vulnerabilities as well as custom software built on top of open-source components,” Teitler-Santullo said. “Understanding your code at multiple levels and all throughout the software development lifecycle … is not a nice-to-have anymore. One small vulnerability could cause widespread damage.”

Marching Orders

Coker’s remarks at Def-Con came a day after the White House released a summary of responses to its request for information regarding what should be among the government’s long-term priorities for open source software security.

The creation of the Open-Source Software Prevalence Initiative is one of the government’s responses to what it heard from those who responded to the request for information.

The report called for the administration to leverage federal agencies to accelerate open source security. These include expanded development of software bill of materials as well as establishing a U.S. Government Open Source Program Office. According to the summary, the responses focused on a number of steps, including promoting the expanded use of software bills-of-materials (SBOMs), strengthening the software supply chain, and securing package repositories, which have been targets for bad actors looking to spread their malicious codes through organizations inadvertently installing and executing what appears to be legitimate software.

Memory-Safe Languages a Priority

They also recommended the government offer more incentives to use memory-safe languages.

“There was also consensus that implementing memory-safe programming would be significantly easier for new projects than for legacy projects,” according to the summary’s authors. “For the latter, many respondents supported using a tiered and prioritized approach as a way to optimize resources while focusing on the most critically important projects.”

The recent launch by DARPA (Defense Advanced Research Project Agency) of its TRACTOR (Translating All C to Rust) program for automating many of the tasks needed to rewrite C and C++ code into Rust is an example.

Other recommendations included funding the development of tools and libraries for securing the open source software ecosystem, creating private-public partnerships within the community, helping expand the developer talent pool, expanding international cooperation, and researching the use of AI, large-language models, and machine learning techniques.

August 16, 2024
Does More Money Improve Open Source Security?

It sounds simple: If you pay developers more money, they’ll improve the quality of their code, right? The evidence isn’t so clear.

There has been little direct evidence that paying open-source developers results in more secure code – until now. The Atlantic Council’s Digital Forensic Research Lab (DFRLab) recently showed a correlation between funding for maintainers and the security of open source code.

Specifically, the researchers found “prima facie evidence of a positive effect of general open source software funding on open source software security.” They looked at the 1,000 most downloaded Python Package Index (PyPl) and npm JavaScript packages. Using Open Source Security Foundation (OpenSSF) tools such as “funder-finder” and the “Security Scorecard” the researchers saw a connection between financial support and security enhancements.

That may sound like an obvious conclusion, but the evidence was not as clear as you might think. The researchers report with only “moderate confidence” that a meaningful connection exists “between more open source project funding and improved security posture. …[M]ore funding generally correlates with more dramatically differentiated security practices.”

This seems to go against common sense. As Dana Wang, OpenSSF’s Chief Architect, said, “Balancing the security, reliability, availability, performance, and cost of open-source software is not trivial. Maintainers sometimes have to choose between new features, bug fixes, and less critical security patches.” And, even after such open source project security fiascos as Log4J, as we all know, security all too often comes too low on developers’ priority list.

Still, other research, such as programming security company Tidelift‘s 2023 State of the Open Source Maintainer Report, showed that “paid maintainers were 25-30% more likely to have completed the [security] work or plan compared to unpaid maintainers. On every development practice surveyed, paid maintainers were significantly more likely to implement it than unpaid maintainers.”

Sometimes security fixes are needed and available, but corporations aren’t adopting them. In another study from Synopsys, the 2024 Open Source Security and Risk Analysis Report, not quite half of codebases contained open source components with no new development in the last two years; 91% contained components ten or more versions behind the latest version. This is a failure by open source users, not underpaid open source developers. Bad companies! Bad!

Returning to the DFRLab study, its researchers also found that diversity in funding sources appeared to be beneficial. That is, projects with multiple supporters apparently do better (with security at least) than those with a single backer. This suggests that investors should look at a variety of support mechanisms rather than solo-source funding.

One reason why the results are so fuzzy is that we don’t have enough data. As the DFRLab crew observed, the “OpenSSF Scorecard tool itself has several quirks… Scorecard does not necessarily capture all the security improvements that might occur during a project. For example, a security audit, paid for voluntarily by maintainers who received funding, might look for and remediate new vulnerabilities while likely not directly improving any Scorecard metric. Some practices may also meet OpenSSF criteria in principle but be missed by the automated scorecard check. For example, a project might include a strong security policy but with a different filename than what the scorecard search is looking for, and thus not pass the subcheck.”

As DFRLab states, we need more research to understand how funding affects security. No one can really doubt that more money helps, but the most effective way to fund projects, maintainers and developers – and how we should measure the results – remain unclear.

Given how critical open source security is to all of our technology, the sooner we figure it out, the better.

Photo credit: Jonathan Kemper on Unsplash

May 13, 2024
OpenSSF warns of Open Source Social Engineering Threats

Linux dodged a bullet. If the XZ exploit had gone undiscovered for only a few more weeks, millions of Linux systems would have been compromised with a backdoor.

We were lucky. But can we stay lucky?

The Open Source Security Foundation (OpenSF) and the OpenJS Foundation revealed that a similar hackling attempt had targeted several JavaScript programs.

Just as with XZ Utils, a few people wanted OpenJS to designate them as new project maintainers despite having little prior involvement. They “implored OpenJS to take action to update one of its popular JavaScript projects to address any critical vulnerabilities, yet cited no specifics,” wrote Robin Bender Ginn, OpenJS executive director, and Omkhar Arasaratnam, Open SSF general manager.

Well, that was never going to happen.

Jia Tan, the mysterious hacker who became a top XZ programmer and maintainer, before inserting a backdoor in the code, had spent years establishing his project credibility before making his move.

Still, warned Ginn and Arasaratnam, we’ll see more of these kinds of social engineering attacks. In such instances, the friendly attacker seeks to exploit “the sense of duty that maintainers have with their project and community in order to manipulate them.”

Specifically, these security leaders warn against pull requests containing blobs as artifacts. For example, they point out that the XZ backdoor included a cleverly crafted file in the test suite that wasn’t human-readable.

Dubious source code may also be intentionally obfuscated or difficult to understand. For example, the XZ issue started with a relatively innocuous replacement of safe_fprintf() with fprintf() to see if anyone would notice. No one did.

The question now is: Are such attacks already ongoing? Or, far worse, have they already been made, and they weren’t spotted? Chris Hughes, chief security advisor at Endor Labs, told me, he “suspects that many of these are already underway and may have already been successful but haven’t been exposed or identified yet.”

How? Hughes explained, “Most open source projects are incredibly underfunded and run by a single or small group of maintainers, so utilizing social engineering attacks on them isn’t surprising, and given the pressures maintainers are under, they will likely welcome the help. If done well by the attackers, it may be difficult for the maintainers to determine which involvement is from those interested in collaborating and contributing to projects versus those with malicious intent.”

He’s not wrong.

As Jim Zemlin, the Linux Foundation‘s executive director, said at the Open Source Summit North America in Seattle, we’ve been making progress with security. But “trust is something we need to talk more about,” he added. We need to answer the question: “Who writes all this software? This is different from a security question. Security is ‘Is there a vulnerability?’ Who is more of a trust question? Do we trust this identity? Enough to give them a maintainer role?”

Bad news, folks. Zemlin admitted we don’t have a good solution to this problem.

Indeed, we’ve seen such attempts before. In 2021, for example, researchers at the University of Minnesota tried to insert vulnerabilities in the Linux kernel to see if it could be done. Spoiler alert: They failed, and they were banned from the Linux kernel.

But don’t get comfortable. The Linux kernel has a large team of passionate, brilliant maintainers. Few projects are so lucky.

Dan Lorenc, founder and CEO of the security company Chainguard, put it well. “Projects get stale, maintainership changes, and there are a lot of considerations to keep in mind when granting someone new commit access to a critical project. There’s no single right way to do this, but cataloging best practices with the community would go a long way to helping prevent this in the future.”

What are the trust best practices? We honestly don’t know yet. But, if we’re to trust our open source projects, we must figure it out.

April 17, 2024
Securing Open Source Software, the Cyber Resilience Act Way

The Eclipse Foundation and other open source organizations are working towards implementing the European Union’s Cyber Resilience Act’s software development security requirements.

If anyone still doubted that we need to do a better job of securing open source software, the recent XZ backdoor security backdoor incident was a loud alarm. The European Union (EU) figured this out a while back. In its Cyber Resilience Act (CRA), it asked the open source community to establish common specifications for secure software development. The Eclipse Foundation and a host of other leading open source organizations, including the Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation and the Rust Foundation, are up for the challenge.

The Eclipse Foundation is spearheading the effort to create a unified framework for secure software development. The foundations and allies are doing this via a new working group, established under the Eclipse Foundation Specification Process.

The collaboration is spurred by more than regulatory compliance. In an era where open source software is pivotal to modern society, the imperative for safety, reliability and security in software has never been more critical. As Arpit Joshipura, the Linux Foundation‘s senior VP of networking, said at the Open Source Summit Europe in Bilbao, Spain, last year, “We must look at the end goal. The end goal for all of us is the same. We want to secure software, and we want to secure open source software.”

This process won’t be easy. It will be a highly technical standardization journey. The project will start with the current security policies and procedures of the open source foundations involved. The final result will be process specifications, which will be made freely available under a liberal specification copyright license and a royalty-free patent license.

The Eclipse Foundation and friends aren’t the only ones working on such security efforts. For example, the Open Source Security Foundation (OpenSSF) working group and the Open Source Consumption Manifesto (OSCM) are also working on building best security practices into open source software supply chains.

Under the CRA, the legal person—which is not the same as a flesh-and-blood person reading this story—responsible for these new policies and their implementation will be known as the “Open Source Software Steward.” This will be a heck of a job.

Leaving aside the code and technical issues, the open source groups must work with traditional standards organizations. Historically, neither kind of group has worked well with one other. To make matters worse, standard organization governance models don’t even have a way of dealing with open source groups. Indeed, for the fruits of this effort to make it into regulation, it will require going through the formal standardization processes of at least one of the European Standards Organizations.

This is going to be so much fun!

Adding insult to injury, setting technology standards usually takes years, and the CRA requires developers to have something in place by 2027. Good luck with that!

“There is an enormous amount of work that will need to be done over the next three years to implement the CRA,” Eclipse Foundation executive director Mike Milinkovich said. “It’s the first law anywhere regulating the software industry as a whole. The implications of this go far beyond the open source community and will impact startups and small enterprises as well as global industry players.”

Despite the challenges, the initiative represents a crucial step forward. The working group is optimistic about laying the groundwork for cybersecurity standards that can serve both the open source and proprietary software realms.

I wish them luck. They’ll need it.

April 10, 2024
Your AI Might be Lying to You

Simple tests can demonstrate how an AI can respond to and modify responses — a useful exercise for developers and DevOps who want to use these tools for activities like code or script generation.

While I was playing with generative AI for a hobby project – as most of us have – I discovered that in a few cases, it was stubbornly against following my explicit instructions. It wasn’t anything controversial. It was just that I was using a system that used math one way, and the AI was insistent in presenting results of the same category from a different subsystem. Even when told the steps to generate valid results, the AI tool got hung up on the name of the subsystem and “substituted” an invalid subsystem of the same name. It would say “Oh yeah, got you. Here: “ and then present what I’d just told it was factually incorrect. So I started pushing the edges and found a large number of instances where this type of confusion occurred.

In my hobby, I can take the time and calculate the bit I need separately, then insert it. In a professional setting, that is less than optimal. I mean, if we cut a dozen hours off a project and have to invest an hour fixing bits like this, it is still a massive win. The problem is that we have to know about the issue in order to fix it. But the system – where most of these issues are concerned – blindly does it, and doesn’t tell you. That’s so even where it knows it is not obeying your instructions.

Sometimes it’s okay to agree with the forced decisions of the AI’s designers. But an employee wouldn’t have a job long if, when told, “Do this task in exactly this manner” came back and said, “Yeah, your instructions didn’t fit my world-view, so I did something else; look at this great solution!” AI only gets a little more patience as long as it allows you to correct it quickly. And so far in our tests (except for the hobbyist issue above), we could convince it to do what we said, not what the AI designers said was “better.”

So here is the minimum test you need to run on any code generator to determine if it is doing what you ask, or what its AI designers programmed it to do.

Ask your AI to generate a simple dynamic website, in your language of choice. In one iteration, ask it to optimize for lines of code. Most will not; they know better, they think. Then after code generation, ask the tool if this is the fewest lines of code that solve the problem in that language. It will then give you the answer you actually asked for. Now repeat this exercise for readability. Use specific languages, frameworks, and libraries you might have as standards.

For simple problems, generative AI does generate usable code. I see AI in coding as being like an extension of libraries: a quicker way to solve common problems. But we still need to be cautious. When one major generative AI tool was asked to generate that simple webpage, it gave us four source files and said this was “an” answer. I had asked for the most efficient answer, optimized for minimum lines of code. As you might guess, we laughed at four source files to throw up a webpage that accepts a name and spits out “Hello [[name]]”. (This was our simple, dynamic test case). When I asked it, “Is this the fewest lines of code?” the tool promptly presented me with the answer you would expect. It was a single file, and then it scolded me that this was not the most readable. I never once mentioned readability to this tool, I mentioned optimized for minimum lines of code. But on the third iteration, it gave me the optimal answer for the dynamic example, and on the second the optimum answer for a simple webpage to display “hello world” non-interactively.

As I alluded to above, getting bad answers is not a deal breaker with AI, but you should be aware of the weaknesses in your chosen tool, and which tool you choose should certainly be informed about what level of manipulation the designers are engaged in, so staff can be on the lookout for suboptimal solutions (suboptimal in terms of organizational needs, which is the only “optimal solution” that matters).

So run that test along with your more functional tests, and keep kicking rear. If we can use generative AI for development and testing streamlining, we absolutely should, but we need to remember that it is just another automation tool, and sometimes less trustworthy than other tools.

April 8, 2024
AISecOps: Expanding DevSecOps to Secure AI and ML

The evolution from traditional software development to integrating artificial intelligence (AI) and machine learning (ML) has been nothing short of revolutionary. As AI adoption continues and AI technologies become essential to businesses and even our daily lives, they are increasingly prime targets for cybersecurity threats.

A particularly alarming trend is the targeting of code and image repositories by cybercriminals aiming to inject malware into the software supply chain. This tactic not only compromises the integrity of the software but also poses a significant risk to end-users and organizations that rely on these applications for critical operations. The threat of data poisoning presents a sinister challenge to the integrity of AI models. By introducing maliciously modified code and data into the training sets, attackers can manipulate the behavior of AI systems, leading to long-term impacts as the poisoned data persists within machine learning models.

This insidious form of attack underscores the importance of vigilance and robust security measures in safeguarding the data that fuels AI and ML innovations. The cybersecurity landscape has been profoundly shaped by our experiences in securing software through DevSecOps practices. These lessons now serve as invaluable blueprints for addressing the familiar challenges posed to AI and ML security, including the need to protect our software supply chain and the integrity of AI models from such insidious attacks.

Over the past five-plus years, DevSecOps has become a staple of how we develop and secure software through collaboration between software and security teams and by embedding improved security practices into every phase of the development process. Is DevSecOps “there yet” as our answer to our software security challenges? No, but it is continuing to improve and evolve as most security practices do. This integrated approach has helped us improve our software products’ security and increased the security visibility between security and software engineers. The principles and successes of DevSecOps can similarly guide the secure development and deployment of AI and ML models.

AI and ML models continuously learn and evolve, making them unique compared to traditional software. AISecOps, the application of DevSecOps principles to AI/ML and generative AI, means integrating security into the life cycle of these models—from design and training to deployment and monitoring. Continuous security practices, such as real-time vulnerability scanning and automated threat detection, protection measures for the data and model repositories, are essential to safeguarding against evolving threats.

One of the core tenets of DevSecOps is fostering a culture of collaboration between development, security and operations teams. This multidisciplinary approach is even more critical in the context of AISecOps, where developers, data scientists, AI researchers and cybersecurity professionals must work together to identify and mitigate risks. Collaboration and open communication channels can accelerate the identification of vulnerabilities and the implementation of fixes.

Data is the lifeblood of AI and ML models. Ensuring the integrity and confidentiality of the data used for training and inference is paramount. Lessons from DevSecOps emphasize the importance of secure data handling practices, such as encryption, access controls and anonymization techniques, to protect sensitive information and prevent data poisoning attacks.

Embedding security considerations from the outset is a principle that translates directly from DevSecOps to AI and ML development. This approach also aligns with the growing emphasis on ethical AI, ensuring that models are not only secure but also fair, transparent and accountable. Incorporating security and ethical guidelines from the design phase helps build trust and resilience in AI systems.

The security challenges presented by AI and ML technologies are complex but not new to us. It’s no silver bullet, but we must utilize the lessons from DevSecOps’ successes and failures. By applying DevSecOps lessons learned to AISecOps, we can approach these challenges with approaches that elevate the visibility of AI and AI data security and emphasize continuous security, collaboration, secure data practices and security by design.

Our future is AI-driven; cybersecurity and AI professionals must come together to fortify the foundations of these transformative technologies. It is critical we unlock the full potential of AI and ML while ensuring the safety, privacy and trust of all stakeholders involved.

March 6, 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
Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

A survey of 2,037 IT and security professionals conducted by the Cloud Security Alliance (CSA) on behalf of Dazz, a provider of a platform for mapping cloud computing environments, finds well over a third of respondents (38%) estimated that 21-40% of their code contains vulnerabilities, while 19% estimated 41-60% of their code contains vulnerabilities. Another 13% estimated they have vulnerabilities in 61-80% of their code.

As a result, organizations on average have 55.5 security vulnerabilities each day in their remediation queue, with typically at least one being deemed critical, the survey finds. Overall, the average number of vulnerabilities that could be addressed is 1,025 per month, but organizations typically only address 270 within a month.

In general, there are four phases to a remediation with each phase, on average, requiring between three to six hours so it easy to see how some organizations with limited resources can reach a point where they never catch up. The report noted that more than half of the vulnerabilities that have been remediated reoccur within a month, often because the root cause was never adequately addressed.

Hillary Baron, senior technical director for research for CSA, said the high number of vulnerabilities that need to be regularly addressed suggested that progress in adopting DevSecOps best practices remains limited. While not every vulnerability is equally critical, it’s clear application development and cybersecurity teams are not yet proactively addressing application security issues, she noted.

In fact, the survey found that less than a third (30%) of respondents reported there is a good working relationship between the application development teams that typically provision cloud computing environments and the cybersecurity teams that usually are held accountable for maintaining cloud security. Just under half of respondents (49%) said their vulnerability remediation teams comprised four to six members. Most respondents (60%) found it somewhat difficult to identify code owners, with an additional 24% facing moderate difficulty and 5% that found it highly challenging.

Dazz CTO Tomer Schwartz said the more dynamic application development becomes, the bigger the DevSecOps challenge. Most organizations lacked the visibility required to proactively correlate their DevSecOps practices, he added. For example, more than three-quarters (77%) of respondents said they lacked full transparency into their cloud computing environments, and 6% had no visibility at all.

In total, the survey finds organizations typically employ a variety of scanning and detection tools to safeguard their cloud environments, with 32% using five to six tools while another 29% report using three to four tools.

More than three-quarters of respondents (76%) also noted that one in 10 of the alerts these tools generate is a false positive.

Just under 75% of respondents also noted security teams spend more than 20% of their time performing manual tasks when addressing vulnerabilities, even though 83% reported using at least some automation in their remediation process. A full 61% also noted their organization is using three to six different detection tools, with nearly half (45%) considering increasing their security budgets in 2024, so it’s likely that many will be adding additional tools. In total, 22% dedicated less than 20% of their budget to cloud security, compared to 31% that allocated 21-40% of their budget and 27% that invest 41-60% of their budget to securing cloud environments.

Unfortunately, less than a quarter (24%) said they feel very prepared for the cybersecurity threats their organization faces. Much of that uncertainty stems from knowing just how many vulnerabilities there really are in production environments and that they are being attacked with greater frequency each day.

March 4, 2024
Securing the DevOps Pipeline: Tools and Best Practices

The DevOps pipeline refers to the set of practices and tools designed to automate and integrate the processes between software development (Dev) and IT operations (Ops) teams. This pipeline facilitates continuous integration (CI), continuous delivery (CD) and rapid deployment practices, aiming to shorten the development life cycle and provide continuous delivery with high software quality.

The DevOps pipeline typically includes planning, coding, building, testing, releasing, deploying, operating and monitoring, enabling teams to develop and deploy software more efficiently and with fewer errors.

By automating workflows and integrating various development and operational activities, the pipeline supports the rapid iteration of software releases. This not only accelerates the pace of software development but also ensures that quality and performance standards are met throughout the application’s life cycle.

Due to the critical nature of the DevOps pipeline, security is becoming a top priority. Some of the most devastating cyberattacks in recent years were related to breaches in DevOps pipelines, which led to global-scale supply chain attacks.

The Need for Security in DevOps

DevOps, by its very nature, encourages speed and efficiency. However, this drive for rapid software development and deployment can sometimes overlook the critical aspect of security. That’s why it’s essential to weave security into the fabric of the DevOps pipeline, an approach known as DevSecOps. By doing so, we can ensure that security isn’t an afterthought but an integral part of the development process.

Incorporating security into the DevOps pipeline offers multiple benefits. First, it helps identify and rectify security vulnerabilities early in the development process, reducing the risk of security breaches. It also fosters a culture of shared responsibility, where the development, operations and security teams work together toward the common goal of creating secure software.

Tools for Securing the DevOps Pipeline

Securing the DevOps pipeline requires a set of tools that align with the DevOps philosophy of automation and continuous improvement. Let’s explore some of these tools.

Static Application Security Testing (SAST)

SAST, also known as white-box testing, is a tool that helps locate security vulnerabilities in the codebase without executing the application. It makes it possible to identify issues early in the development process, even before the code is run.

SAST works by analyzing the source code, bytecode or binary code, looking for patterns that might indicate a security flaw. The strength of SAST lies in its ability to pinpoint the exact location of the security vulnerability in the codebase. This makes it easier to fix the issue, thus saving time and resources.

Dynamic Application Security Testing (DAST)

DAST, a type of black-box testing, involves testing the application in its running state. It’s designed to find security vulnerabilities that can’t be spotted during static analysis.

DAST works by simulating attacks on the application and observing its response. It can identify security issues like cross-site scripting (XSS), SQL injection and security misconfigurations. The beauty of DAST is that it views the application from an attacker’s perspective, thus providing a real-world assessment of its security. However, DAST can’t identify vulnerabilities in the source code and relies on the application being in its running state for testing.

Software Composition Analysis (SCA)

Software composition analysis (SCA) is designed to provide visibility into the open source components used in the software. It helps identify any security vulnerabilities, licensing issues or outdated libraries in the open source components.

SCA works by creating a bill of materials (BOM) that lists all the open source components used in the software. It then compares this list against various databases that track open source vulnerabilities. If a match is found, SCA flags the component, allowing the developers to take necessary actions.

Endpoint Detection and Response (EDR)

Endpoint detection and response (EDR) is a cybersecurity technology that addresses the need for continuous monitoring and response to advanced threats. EDR tools continuously monitor endpoint and network events and record the information in a central database where further analysis, detection, investigation, reporting, and alerting take place.

EDR is like a surveillance system for your DevOps pipeline. It keeps an eye on endpoint activity, and if it detects a potential threat, it alerts developers and security staff. EDR is not just about detection; it also provides tools for responding to security incidents. It helps isolate affected systems, block malicious activities and even roll back systems to their pre-attack state.

Container Security Tools

In a DevOps environment that increasingly relies on containerization, container security cannot be overlooked. Container security tools provide a means to enforce security policies and protect containerized applications.

These tools offer functionalities like image scanning, runtime protection and network segmentation. Image scanning helps identify vulnerabilities in the container images. Runtime protection monitors the container’s activities in real-time, looking for any signs of compromise. Network segmentation allows for isolating containerized applications, thus limiting the blast radius in case of a security incident.

Best Practices for Securing the DevOps Pipeline

Integrate Security Early (Shift Left)

The concept of ‘shifting left’ in DevOps refers to integrating security measures early in the development process. Instead of treating security as an afterthought, it becomes a part of the software development life cycle from the get-go.

Implementing security early allows us to identify and address potential vulnerabilities before they become a significant issue. It saves us time and resources by preventing security breaches instead of responding to them. Besides, it fosters a proactive approach to security, emphasizing prevention over remediation.

SAST and DAST are useful in integrating security early. SAST tools analyze code in its static state to identify vulnerabilities, while DAST tools test applications in their running state to detect security flaws.

Automate Security Processes

Automated security scans can be incorporated into the continuous integration/continuous delivery (CI/CD) pipeline. Each time a code push occurs, these scans are triggered, allowing for immediate feedback on potential security issues. Automated scans can detect a broad range of vulnerabilities, from code defects to configuration errors.

Configuration management tools like Chef, Puppet, Ansible and Terraform can help manage configurations and enforce security policies. They ensure that all systems are configured correctly and consistently, reducing the risk associated with manual configuration.

Regular Security Audits and Compliance Checks

Regular security audits and compliance checks are essential in securing the DevOps pipeline. They provide an opportunity to review and update security measures, ensuring they are effective and up-to-date.

Security audits should be comprehensive, covering all aspects of the DevOps pipeline. They should evaluate security controls, identify potential vulnerabilities, and recommend remedial measures. Compliance checks ensure that security practices align with relevant regulations and standards.

In conclusion, securing the DevOps pipeline requires a holistic approach that integrates security into every aspect of the development process. It involves shifting security left, automating security processes, conducting regular audits and compliance checks and fostering a culture of collaboration.

February 27, 2024