devopsy.kinsta.cloud

Tag: CISA

Open Source Code Just as Secure as Proprietary Software—If You Manage It Right, Says CISA
Open source can be just as safe as proprietary software, though government agencies (and private enterprises) should take additional measures to secure it properly, according to a new guide published by the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

The report, “Open Source Software: Security Principles and Practices,” provides with guidance to help agencies comply with two Presidential Executive Orders (14144 and 14306) which both urged them to do a more thorough job securing the software they use, a response to recent exploits like Log4Shell and XZ utils.

CISA acknowledges that open source can provide immeasurable benefits to government agencies, not merely because it is available without licensing fees, but also because agencies can extend the software to meet their own requirements. But at the same time, open source software must be managed differently than proprietary software.

Malicious hackers (and increasingly AI agents) use vulnerabilities to gain entry and exploit systems. In the case of the vendor software, it is the vendor’s responsibility to provide timely updates should a software vulnerability be found, which agencies should apply as soon as possible.

With open source software, however, agencies need to take a more proactive role in patching and understand the dependencies, or additional software components, that an open source package relies on. Those components also need to be secured, the guidance advises.

The guidance describes established principles for patching. It also provides a framework to evaluate trustworthiness and risk tolerance of software packages, as well as a set of best practices to procure, deploy and maintain open source software.

In practical terms, agencies wishing to use open source should establish a process that supports staff in choosing the software that meets the agency’s needs but minimizes risks to the agency.

For instance, an agency’s Office of the Chief Information Officer may set up a system to pre-approve certain software libraries for use in the agency. Automated tools could help verify safe software packages, and reviews would consider potential risk exposure. The CIO could still individually sign off on higher-risk components, such as operating systems.

To help agencies, CISA produced the C4 Framework, which can be used to assess the trustworthiness of a software package. It looks at four factors (the four Cs):
- Codebase: Take a look at the actual source code and dependencies that make up the software component of interest. How recently was the last update committed? How many vulnerabilities have been found? How many out-of-date dependencies does it rely on?
- Community: How robust is the community that maintains and contributes to the project? Is it part of a foundation, or managed by a private company?
- Conduct: How is the project managed? Is there a vulnerability disclosure process? Do the project leaders follow their own code of conduct?
- Configuration: Is the default configuration secure? Are there guides for use in highly-sensitive environments?
Open source AI systems should go through additional checks, CISA recommends. Agents should get sufficient transparency into the training data, in addition to the software itself. “Only with transparency and access can agencies understand and study the software, analyze it for vulnerabilities, and remediate any found vulnerabilities or risks,” the guide recommends.

CISA has targeted this report to U.S. federal agencies, though the advice here is rock-solid for use in the industrial sector as well. Many businesses in finance and health care, for instance, routinely follow government guidance. So if your organization uses open source in any capacity, this report may be worth checking out.
July 31, 2026
CISA’s 2026 SBOM Guidance Adds Hash Requirements and AI Coverage

CISA just gave software supply chain security a long-overdue refresh. Working with the NSA, the FBI, and a roster of international partners, the agency released the 2026 Minimum Elements for a Software Bill of Materials, updating and replacing the baseline that the National Telecommunications and Information Administration published back in 2021. Five years is a long time in software security terms, and the update shows.

The timing isn’t random. The revision incorporates feedback from more than 90 comments submitted during a public comment period, and CISA circulated a draft in 2025 specifically to update elements like SBOM author, software producer, and component version for better clarity. This wasn’t a quiet policy tweak. It was a deliberate, multi-year rework built on real feedback from people who actually generate and consume SBOMs for a living.

What’s New

The headline change is scope. The minimum elements now apply to SBOMs across all software types, including open-source software, AI software, and software-as-a-service. That’s a meaningful expansion from 2021, when the guidance was written before AI systems and SaaS delivery models were the default rather than the exception.

The second big change is data quality. According to one industry summary of the release, the guidance adds new required minimum data fields, including component hash algorithm, component license, SBOM tool name, and SBOM generation context. It also renames several existing elements for consistency, with “Supplier Name” becoming “Component Producer”.

The hash requirement deserves its own paragraph, because it closes a real gap. A package identifier tells a scanner what a component is supposed to be. It doesn’t tell you what the component actually is. If someone swaps out the contents of a library while leaving the name and version untouched, the identifier looks fine, and the vulnerability scanner has no idea anything changed. A hash captures the actual bytes of the file. Requiring it in every SBOM means organizations finally get a way to verify that what’s documented matches what’s deployed, not just what’s claimed.

CISA was careful to note that this is a floor, not a ceiling. While the minimum elements apply to all software, certain types, like AI and cloud-based SaaS, may need additional elements beyond the baseline, and any effort to improve transparency should start with these minimum elements regardless of software type. That framing matters for teams trying to figure out where to start.

But extending the baseline to AI and SaaS creates a practical problem most build pipelines aren’t set up to handle. “Extending the baseline to AI and SaaS moves the work from your build pipeline to your vendor contracts. You cannot hash a binary you never compile. The SBOM has to arrive with the service,” says Mitch Ashley, VP and practice lead, software lifecycle engineering and AI-native software engineering at The Futurum Group.

Where This Fits in the Broader Picture

This update doesn’t exist in isolation. Earlier this year, CISA and G7 partners released a companion document specifically for AI systems, aimed at helping public and private sector stakeholders improve transparency into AI supply chains, and that guidance was explicitly framed as supplemental to the general SBOM minimum elements, since AI systems are still software systems but bring extra components like models, datasets, and other AI-specific artifacts. The 2026 baseline and the AI-specific guidance were clearly built to work together.

AI adds a wrinkle that traditional SBOM programs weren’t designed around. “AI is harder, because a model or dataset can change without a build ever running. Programs keyed to release events will miss those changes. Decide which components you require SBOMs for and write it into renewal terms,” Ashley says.

There’s a second, quieter problem underneath all of this, and it doesn’t go away just because the guidance got better. Justin Beals, CEO and founder of Strike Graph, argues the harder issue was never producing the document. “Plenty of organizations can produce an SBOM document. Far fewer can prove the components listed in it are still accurate six months later,” he says. As SBOM requirements get pulled deeper into frameworks like CMMC and FedRAMP, Beals sees that gap becoming the real point of failure: “It’s the same gap we see across every framework leaning on SBOMs right now: a static list, filed once, treated as proof of ongoing security. It isn’t. It’s a snapshot.”

It’s also worth noting what’s changed on the federal enforcement side. In January 2026, OMB issued M-26-05, which rescinded prior mandatory self-attestation memoranda in favor of an agency-led, risk-based approach, even though Executive Order 14028 itself remains in effect. So the federal posture is shifting away from blanket mandates and toward agencies making their own risk calls. That makes clear, well-structured minimum elements guidance more important, not less. Agencies need a solid baseline to build risk-based decisions on top of.

What This Means for Practitioners

If your organization already generates SBOMs in CycloneDX or SPDX format, most of the new fields are additive rather than disruptive. Both formats already support hash-based component identification, so adding hash values is a configuration change in your build pipeline rather than a format migration. The bigger lift is Ashley’s point: for AI models, datasets, and SaaS, there’s no build event to hook into. That means rethinking SBOM requirements as contract terms with vendors, not just pipeline automation.

Beals’ point builds on that. Producing the document, even a better-structured one, still isn’t the finish line. The organizations that get ahead of this, he says, will be the ones that build continuous validation into their SBOM process instead of generating it once to check a box. That’s the difference between attestation and evidence.

For teams that haven’t started, this is a reasonable moment to pick a format and get moving. Neither CycloneDX nor SPDX is mandated here, and both are mature enough to cover the new required fields. The bigger risk is waiting for a mandate that, given the OMB shift, may never arrive in the blanket form people expected. Risk-informed procurement and vendor contracting are happening now, with or without a federal stick attached.

July 31, 2026
Cybersecurity Laws Will Shape the Future of DevOps
DevOps thrives on speed. Fast releases. Rapid iterations. Agile workflows. But there’s one thing moving just as fast—cybersecurity regulation. From the EU’s NIS2 Directive to the U.S. SEC’s breach disclosure rules, governments are turning up the heat on software security.

For DevOps teams, this means the days of treating security as a bolt-on afterthought are over. The era of “compliance-driven development” is here. And if your pipeline isn’t built to adapt, it’s going to break.

The Legal Landscape is Closing in on Code

Cybersecurity law isn’t just catching up to software—it’s overtaking it. The once-blurry lines between compliance, governance, and DevOps are being redrawn in real time. Countries like Germany, the U.S. and Singapore are pushing mandates that require software-producing companies to embed security from the start.

The EU’s NIS2, for instance, directly calls out software development lifecycles as part of critical infrastructure. That means developers, and yes, DevOps engineers, are now on the hook. The

U.S. Cybersecurity and Infrastructure Security Agency (CISA) is rolling out Secure by Design initiatives, shifting liability onto vendors. The White House’s Executive Order 14028 sets new expectations for SBOMs (software bills of materials), continuous monitoring, and zero trust frameworks baked directly into dev pipelines.

What this all means: DevOps isn’t just about building software anymore. It’s about building compliant software. Every production push now has a legal context, and failure to meet regulatory expectations won’t just cost you uptime—it could cost you millions.

Shift Left or Get Left Behind

The “shift left” mantra has echoed in DevOps for years. But what used to be a best practice is becoming a legal necessity. Under evolving cybersecurity laws, secure coding practices and early vulnerability detection aren’t optional—they’re enforceable.

Security testing tools like SAST, DAST, and SCA are being redefined not as tools for the security team, but as core DevOps utilities. Teams must embed them directly into CI/CD pipelines and prove that they ran before code was ever deployed.

This shift has implications far beyond tooling. It redefines roles. Developers are now expected to understand threat modeling, too. Ops teams must know how to respond to zero-days in real time. And CISOs are becoming stakeholders in the DevOps lifecycle itself.

Teams that resist this shift? They’ll find themselves in technical debt and regulatory debt at the same time—a double-bind that startups and enterprises alike are unprepared to handle.

Compliance is an Operating Model, Not a Checklist

DevOps has always been about culture. But as regulatory scrutiny intensifies, compliance culture must become part of the DevOps DNA. This doesn’t mean turning developers into auditors. It means reimagining compliance as a continuous function, not a quarterly fire drill.

DevSecOps is a start, but many implementations fall short. Security gates are bolted onto workflows, documentation is treated as a nuisance, and compliance is viewed as “somebody else’s job.” That approach won’t cut it anymore.

Under NIS2 and similar regulations, your organization must prove due diligence at every step:
- Secure architecture design
- Access control policies
- Incident response drills
- Recovery planning
- Third-party risk assessments
This is especially important in the context of HIPAA-compliant hosting, where failing to log and control access to sensitive health data can result in severe penalties. The same goes for banking and any other industry where an impervious security system is paramount.

To survive in this new landscape, DevOps must evolve into RegOps. That means pipelines designed with traceability, auditability, and governance in mind. Infrastructure as Code must be versioned and reviewable. Secrets management can’t rely on obscurity. Every change must be accountable.

Tooling Will Evolve—But Culture Must Lead

It’s tempting to reach for the latest compliance plugin or cloud-native security scanner and think the job’s done. But compliance isn’t something you install. It’s something you live. And DevOps culture has to lead the way.

The future of DevOps tooling will be shaped by regulation. Expect to see integrations between CI/CD platforms and governance frameworks. More GitOps platforms will offer native support for SBOMs. Infrastructure-as-Code policies will trigger real-time alerts when changes break compliance standards.

But none of that matters if your teams treat security as friction. The key isn’t just tooling, it’s trust. Developers need to trust that security tools won’t slow them down. Security teams need to trust that developers understand the stakes. And leadership needs to trust that their DevOps culture can scale with legal complexity.

This is where high-performing teams will separate themselves. They’ll invest in cross-training. They’ll create feedback loops between security and dev teams. They’ll automate not just deployments, but documentation. In short: They’ll treat compliance as code.

Incident Reporting and the Death of the “It Won’t Happen to Us” Mentality

Breaches are no longer just IT’s problem. Under laws like the SEC’s 2023 disclosure rules, they’re now a boardroom crisis. If your DevOps practices can’t support real-time incident response and breach disclosure, your org is exposed—legally and reputationally.

Most teams still rely on fragmented postmortems, chat logs, and intuition during incidents. That’s a recipe for disaster when legal teams need precise timelines, impacted systems, and communication trails within hours—not weeks.

Thus, it’s safe to conclude that modern DevOps must include playbooks not just for recovery, but for legal disclosure. Runbooks must cover not only rollbacks and patches, but who gets alerted, how, and when. Git logs and build artifacts need to serve as legal documentation.

Traceability isn’t a nice-to-have. It’s required.

This shift changes the game for SREs and platform engineers, too. Observability must now include forensics. Uptime isn’t the only SLA anymore—transparency is.

Global Fragmentation Will Demand DevOps Agility

If your application runs across regions, your compliance burden isn’t just bigger—it’s fractured. Different countries are introducing overlapping, sometimes conflicting, cybersecurity regulations. DevOps teams must become geopolitical navigators as much as engineers.

Take data residency requirements. In one jurisdiction, your logging solution may be fully compliant. In another, it could be a violation. SBOM disclosure formats may vary between the U.S. and EU, not to mention that even encryption standards aren’t globally harmonized.

This means your CI/CD pipeline can’t be monolithic. It must be context-aware. Automated branching workflows by geography. Conditional logic for compliance checks. Regional infrastructure provisioning. All of it must be baked into your delivery architecture.

The most resilient DevOps orgs will treat legal variability like they treat infrastructure variability: with abstraction, modularity, and automation. Just like cloud-native systems flex to support scale, compliance-native DevOps must flex to support regulation.

Conclusion

The future of DevOps isn’t just agile—it’s accountable. Regulatory scrutiny is forcing a shift in how we build, test, and ship software. It’s no longer enough to move fast and fix things. Now, we must move deliberately and document everything.

Cybersecurity laws are evolving into a new kind of architecture constraint—one that defines not just what you build, but how you build it. Teams that embrace this reality will turn compliance into a competitive advantage. Those who ignore it? They’ll find themselves fighting fires with legal consequences, not just operational ones.

The bottom line: DevOps is no longer just about speed. It’s about trust, transparency,and resilience in a world where software eats law—and law bites back.
November 3, 2025
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
Most Critical Open Source Projects Lack Memory-Safe Code, CISA Says

The country’s top cybersecurity agency is continuing to urge software developers to adopt memory-safe programming languages to help reduce the number of vulnerabilities in their products, most recently through a report showing that more than half of widely used open-source projects contain memory-unsafe code.

CISA and the FBI also found that 55% of the lines of code in the projects were written in memory-unsafe languages and that the largest projects disproportionately were written in such languages. In addition, even projects that were said to be programmed in memory-safe languages included some components created with memory-unsafe code.

In the joint 22-page report released this week and developed in conjunction with counterparts from Canada and Australia, the agencies recommended software makers create roadmaps for transitioning to memory-safe roadmaps, including plans for addressing memory safety in external dependency, which tend to include open-source software (OSS).

The report, “Exploring Memory Safety in Critical Open Source Projects,” “provides a starting point for these roadmaps by investigating the scale of memory safety risk in selected OSS,” the agencies wrote.

CISA and other government agencies for more than a year have been beating the drum for memory-safe languages, encouraging developers to migrate away from C and C++ and adopting such languages as Rust, C#, Go, Java, Python and Swift.

A Needed Change

Such a transition will eliminate many of the memory safety issues that have haunted software developers for decades and account for the most common flaws in software, according to CISA. These vulnerabilities affect how memory is accessed, written, or allocated in ways never intended in the programming languages.

They can lead to more updates, patching and incident responses that can cost both the software maker and their users. The vulnerabilities also open up the software to exploitation by bad actors. The flaws can include buffer overflows, use of uninitiated memory and use after free.

Memory-safe languages essentially prevent programmers from creating code that can lead to memory bugs and security flaws by including features that automatically catch memory access errors, like dangling pointers and buffer overflows, at the compile time and runtime stages. C, C++, and similar non-memory safe languages don’t have such automatic functions, which leads to more bugs ending up in the final version of the code.

“Memory-unsafe languages require developers to properly manage memory use and allocation,” the agencies wrote in the report. “Mistakes, which inevitably occur, can result in memory-safety vulnerabilities such as buffer overflows and use after free. Successful exploitation of these types of vulnerabilities can allow adversaries to take control of software, systems and data.”

That said, “memory-safe languages shift the abstraction layer and responsibility for writing memory-safe code from the developer to the compiler or interpreter, vastly reducing opportunities to introduce memory-safety vulnerabilities.”

More Work to Be Done

The 172 open-source projects analyzed came from the Open Source Security Foundation (OpenSSF) Securing Critical Projects Working Group’s list of critical projects.

The agencies found that even for projects written in memory-safe languages, there still can be memory safety flaws.

“This can be caused by direct use of memory-unsafe languages or external dependency on projects that use memory-unsafe languages,” they wrote. “Additionally, low-level functional requirements to disable memory safety may create opportunities for memory safety vulnerabilities in code written in otherwise memory-safe languages. These limitations highlight the need for continued diligent use of memory-safe programming languages, secure coding practices and security testing.”

Not Always an Easy Transition

Neatsun Ziv, co-founder and CEO of OX Security, said he wasn’t surprised that many of these projects use memory-unsafe languages. A barrier to shifting to memory-safe code is the prevalence of legacy systems built with C and C++.

“Rewriting these in modern, memory-safe languages is not only costly but also complex, potentially leading to disruptions in critical business operations,” Ziv said. “The key challenge lies in balancing enhanced security with the financial implications.”

He recommended companies create detailed plans for migrating to memory-safe languages, including prioritizing the most critical components first. In addition, they should use advanced code analysis tools and compilers to automatically detect and correct unsafe coding practices and establish clear governance frameworks that integrate memory safety and secure coding practices across the software development lifecycle.

“Focusing on memory safety is crucial for enhancing the security of future software development,” Ziv said. “However, transitioning from existing systems involves significant upfront investment and careful weighing of costs, benefits, and potential security compromises for each organization, which is why it’s taking a significant amount of time for enterprises to make the switch.”

Building the Case

The report builds on another document, “The Case for Memory Safe Roadmaps,” which CISA and agencies in other countries released in December 2023. CISA Director Jen Easterly at the time put adopting memory-safe coding into national security terms and said it was a key part of the federal government’s Secure By Design initiative to encourage developers to integrate security capabilities throughout the entire software development lifecycle rather than bolting it on at the end.

It also in line with another push by the Biden Administration to lift the responsibility of securing software and other technologies from the users and put it on the shoulders of developers.

In February, the White House issued a technical report that reinforced the argument that greater use of memory-safe languages would eliminate a range of security flaws, with National Cyber Director Harry Coker saying in a statement that “we, as a nation, have the ability – and the responsibility – to reduce the attack surface in cyberspace and prevent entire classes of security bugs from entering the digital ecosystem.”

June 28, 2024
CISA, NSA Issue Supply Chain Security Guidance Report

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

November 21, 2023
I Guess This is Growing Up: Devs and CISA’s Secure-by-Design Guidelines

With the downward pressure of a global recession, inflation and general post-pandemic turbulence underpinning disruption to multiple facets of life, it seems only fair that we in the IT, software and security industry would eventually feel the winds of change, too. We have rolled with the punches of escalating cybercrime and data breaches; the collective, fragmented sheriffs of a digital Wild West, and it’s high time we updated our strategy for safeguarding software against bad actors who seek to do widespread harm.

The recently released National Cybersecurity Strategy signals the need for a seismic cultural shift for most companies and their developers and DevOps teams. The most glaring recommendation comes in the form of security accountability that falls primarily on software vendors. This is a positive step, though it is sure to cause teething problems, especially as many organizations struggle to accurately assess their security maturity across the board, particularly among the development cohort.

Since CISA Director Jen Easterly’s trailblazing speech on secure design principles, we have eagerly awaited formal guidelines on how, exactly, organizations can approach this significant restructuring of software development as we know it. Thanks to a collaborative effort between the cybersecurity authorities of seven countries, we have a rather comprehensive overview of how to drive down vulnerabilities in software.

This should be cause for celebration, but understandably, there is hesitation about how this will impact innovation, feature delivery and, ultimately, the bottom line as the pressure of security stewardship mounts for vendors. We’ve grown accustomed to dealing with cumbersome tooling that is ill-fitted with developer workflows, overwhelming them with a list of fixes in an information avalanche. Add SCA and SAST scanning, and you’ve got thousands of identified issues in a codebase that are just not practical to solve.

Despite this, in terms of our collective attitude towards code-level security, is it time we grew up and faced the music?

Security Commitment and Transparency Boost Our Potential

Back in March, the White House announced that one of its top priorities in the National Cybersecurity Strategy was to shake things up and start holding entities liable for sloppy software security measures:

“Companies that make software must have the freedom to innovate, but they must also be held liable when they fail to live up to the duty of care they owe consumers, businesses or critical infrastructure providers,” the White House noted in the strategy.

In the era of “speed at all costs” software development, my opinion may be unpopular, but I truly stand behind the idea that coding with security front-of-mind from the beginning is the only way we safely create our digital future. We were already facing insurmountable challenges with data breaches, nation-state attacks and infrastructure disruption, and that was before code-capable AI tools hit the mainstream. Until every person touching code cares more about the security implications of their actions, we will continue to see cybersecurity issues surge at a rapid rate.

I know this is easier said than done. I have a lot of empathy for those standing at the bottom of this steep mountain trying to change the conversation around security accountability and enable developers in their organizations to share responsibility. To adequately fulfill key secure-by-design principles in software development, it is going to require precision training that establishes a basic skillset before deep-diving into more advanced security architecture methods. Developer-led threat modeling is a golden opportunity for the AppSec and development teams to work together toward a common goal and explore access control and insecure design pitfalls that plague less mature organizations.

Still, the core issue has always revolved around a lack of ownership for security (until something goes wrong—then it’s the AppSec team left holding the bag) coupled with a low appetite for best practices to be established and executed across every part of the SDLC. The truth is, it was never acceptable for developers to start coding with so little security expertise, nor for us to focus on speed and functionality at the expense of safety and quality. Yet, here we are, and this is our crucible moment to accept shorter-term pain for longer-term ongoing success.

We should want to create the most secure, robust software possible, and the “radical transparency” called for by Jen Easterly is a boon to vendors and clients alike. It is definitely a mark of value to showcase the company’s security prowess; brand trust and reputation are everything in this hyper-competitive landscape.

Developers Need Guidance and Support to Thrive in a Secure-by-Default Environment

The CISA guidelines pay particular attention to open-source and third-party components, both of which are widely used in most software development projects. It is imperative that developers are sufficiently security-aware to navigate potential inherent bugs with any preexisting code they use. However, in addition, they must be able to apply working knowledge of security fundamentals in the languages and frameworks they actively write in every day. Annual compliance videos played at 2x speed won’t cut it; they need training and a tech stack that is hyper-relevant, easy to access without context-switching from their workspace and that ultimately drives them to apply secure coding best practices as second nature.

They cannot do this alone, and they can’t be expected to upskill in their own time. The cultural shift required to make the development team a fundamental cog in a thriving security program takes courage, time and commitment. But the reward is cohesion between AppSec and developers that would have been virtually impossible a decade ago and software that stands above those who are, in one way or another, happy to let security slide despite the risks.

I guess this is what growing up looks like for all of us in the software industry, and it’s crucial if we want to stop the same old vulnerabilities that have plagued us for so long that they are old enough to drink.

May 31, 2023
Federal Agencies Share DevSecOps Guidelines

The National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) have published a set of DevSecOps best practices based on the Enduring Security Framework (ESF).

Developed by a public-private cross-sector working group led by NSA and CISA, the ESF framework was created in the wake of the breach of the SolarWinds software supply chain that led to malware being distributed downstream to a number of organizations that relied on the company’s IT management platform.

The Securing the Software Supply Chain for Developers set of best practices published by NSA, CISA and ODNI takes the ESF a step further. The guidance walks organizations through the processes required to develop secure code, verify third-party components, harden build environments and deliver code.

The best practices provided are the latest dividend of an executive order issued by the Biden administration that requires every federal agency to review the security of its software supply chains. The expectation is that enterprise IT organizations will conduct similar reviews using the best practices and frameworks defined by the federal agencies that specialize in cybersecurity.

The challenge, of course, is embedding those best practices within existing DevOps workflows. In theory, more responsibility for cybersecurity is shifting left toward application development teams. However, the level of cybersecurity expertise that exists today among application developers is limited at best. Cybersecurity was an elective in most developers’ training and education programs, so it should come as no surprise that few of them ever attended a cybersecurity class.

There’s a clear need to improve cybersecurity training for developers, but the real work involves automating cybersecurity processes within the workflows managed by the tools developers employ to write code and the platforms that DevOps teams use to deploy applications, said Mitch Ashley, principal analyst for Techstrong Research, an arm of Techstrong Group that is also the parent company of devopsy.kinsta.cloud. “Security needs to be part of the toolchain, workflows and how the software is designed,” he said.

Ideally, organizations should appoint a security champion that will work with development teams to consistently implement a set of DevSecOps best practices, added Ashley.

Of course, the security champion doesn’t eliminate the need for cybersecurity professionals. Rather, it reduces the pressure when there is a chronic shortage of cybersecurity professionals. In the absence of any formal cybersecurity review during the application development process, it’s simply too easy for developers to inadvertently introduce malware into a software component or misconfigure a cloud infrastructure service. In either case, cybercriminals are increasingly finding it easier to compromise software supply chains at multiple points.

It’s not clear how much the federal government’s guidance might impact the overall state of application security. However, one way or another the level of security scrutiny being applied to how applications are built and delivered is only going to increase in the months ahead. The challenge is finding a way to deliver secure code without necessarily slowing down the rate at which applications are currently being built and deployed.

September 6, 2022
Live Fireside Chat with Christopher Krebs: How to Combat Disinformation

We live in a digital world where most information is now found online. This makes it increasingly difficult to verify the veracity of information. Threat actors have been taking advantage of the digital landscape to spread disinformation, propaganda and conspiracy theories to manipulate the public and sow doubt, discord and chaos. How can we distinguish between fact and opinion, truth and supposition? How can we spot fake news and tackle disinformation?

Former Director of the Department of Homeland’s Cybersecurity and Infrastructure Security Agency (CISA) and Co-Founder of Krebs Stamos Group, Christopher Krebs, will be speaking about disinformation at this year’s DevOps Connect: DevSecOps on May 19 at 12:00 p.m. EDT. During his keynote session, Krebs will explain what disinformation is, how to recognize fake news and the challenges disinformation poses to cybersecurity teams. He will reveal effective ways to combat disinformation, and how public and private partnerships can help. Krebs will also be answering questions from the audience during the live Q&A session.

Krebs is a founding partner of the Krebs Stamos Group, and previously served as the first director of the federal CISA for two years. Before that, he served in various roles at the Department of Homeland Security (DHS), responsible for a range of cybersecurity, critical infrastructure and national resilience issues. He has also directed U.S. cybersecurity policy for Microsoft and advised industry and government clients on complex cybersecurity and business risk matters while serving in positions with Obsidian Analysis and Dutko Consulting.

DevOps Connect: DevSecOps has been part of the RSA Conference for six years in a row. This year, the main focus of the event is on “Securing the Cloud Native World.” Krebs has joined a stellar lineup of DevOps, cybersecurity and IT thought leaders as the DevOps Connect 2021 featured keynote speaker. Attend his live session, “Disinformation: As Dangerous as Cyber and Physical Threats,” and check out all the other breakout sessions to learn more about cloud security, DevSecOps, cybersecurity threats—such as disinformation—and more.

For more information and to register for free, visit the DevOps Connect 2021 website. Save your spot today and learn how to better secure, monitor and maintain the security of your systems.

May 3, 2021
Christopher Krebs to Keynote in Live Fireside Chat/Q&A Session at DevOps Connect: DevSecOps at RSA Conference 2021
Former Director of Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) to headline free one-day event

Boca Raton, FL, April 26, 2021 — MediaOps, the place to tell your story in the most powerful way, today announced that Former Director of the Department of Homeland’s Cybersecurity and Infrastructure Security Agency, Christopher Krebs, will be its keynote speaker at DevOps Connect: DevSecOps, a free one-day virtual event to take place on Friday, May 19, during the week of RSA Conference 2021. For the keynote session, Krebs will participate in a live fireside chat with MediaOps Founder and Editor-in-Chief Alan Shimel, which will also include questions fielded from attendees.

“I am excited to have Chris headline our DevOps Connect: DevSecOps security event at RSA Conference this year. His experience in both the public and private sector of managing risk to businesses and government agencies, enabling them to defend themselves against cyber and physical threats is impressive. Chris probably knows as much about election security and working in a public-private partnership to safeguard our critical infrastructure as anyone. I look forward to an engaging discussion with him,” said Shimel.

Krebs is a founding partner of the Krebs Stamos Group, and previously served as the first director of the federal Cybersecurity and Infrastructure Security Agency (CISA) for two years. Before serving as CISA Director, Krebs served in various roles at the Department of Homeland Security (DHS), responsible for a range of cybersecurity, critical infrastructure and national resilience issues. Prior to his time at DHS, he directed U.S. cybersecurity policy for Microsoft and advised industry and government clients on complex cybersecurity and business risk matters while serving in positions with Obsidian Analysis and Dutko Consulting. Finally, he also served in the George W. Bush Administration, advising DHS leadership on domestic and international risk management and public-private partnership initiatives.

Krebs holds a Bachelor’s degree in environmental sciences from the University of Virginia and a J.D. from the Antonin Scalia Law School at George Mason University.

For the sixth year in a row, DevOps Connect: DevSecOps is again part of the RSA Conference. Each year, MediaOps puts together a line-up of internationally recognized speakers to bring security and DevOps professionals the best in peer-to-peer knowledge exchange. In addition to keynote speaker Christopher Krebs, this year’s event features a powerhouse lineup of 30 cyber DevSecOps experts.

Additional Resources
About MediaOps

MediaOps, the place to tell your story in the most powerful way, is an omniversal media company covering IT industries and practices that are re-shaping the world of technology, including DevOps, Cloud-Native, Cybersecurity and Digital Transformation. Through a convergence of new media distribution platforms, we deliver the experiential stories IT professionals need to gain fresh insights and learn new skills. For marketing partners, MediaOps delivers unparalleled access to inform and engage with a highly involved IT community, for thought leadership, demand generation and specialized campaigns. MediaOps is not only the most trusted name in technology media, but the most loved as well.

###

Contact

Rebecca Auguste

rebecca@mediaops.com

(561) 430-3347
April 26, 2021