devopsy.kinsta.cloud

Tag: secure-by-design

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
Secure By Design, Secure by Default

“Shift left” has become a favorite mantra of engineering, IT and software teams. The idea is simple: Move critical practices earlier in the development process so that problems can be caught sooner and fixed more cheaply. It started with testing, then design, then DevOps, and now it’s security’s turn. Secure by design, secure by default. Just shift it left.

But there’s a problem. If you shift everything left, what’s on the right?

The term “shift left” sounds appealing, but it’s based on the notion that software development is a neat, linear process with design on the left and production on the right. That model might make sense on a Gantt chart, but real-world software is complex and messy. And complex and messy have important implications for how to think about security.

Code (and attack surfaces) don’t flow from left to right. They unfold across overlapping zones of activity that run in parallel. Some people are designing, some are coding, some are deploying, and others are investigating anomalies in production – all at the same time.

Security Needs to be Embedded

Security isn’t something you can “move left”. It’s something that needs to be embedded in all zones.

DevOps security is an extension of and should still conform to the organization’s overall enterprise security, compliance and governance policies. This ensures that the code that is developed and deployed meets the organization’s security requirements.

Optimize within a zone, sure. It’s important to do as much as possible early: threat modelling, secure coding and static analysis. That’s good hygiene. But those only address the development zone. The real world doesn’t stop there. Security in the production zone is just as critical: monitoring, detection, alerting, incident response and continuous improvement. These aren’t things you can shift anywhere. They’re tied to live, active systems. They happen where the threats are.

The irony is that shifting security left too far can give teams a false sense of safety. Boxes are ticked. Static scan looks good, threat modelling is done, so we must be secure. But attackers don’t care how early your checklist ran. They’re looking at the state of the system now.

The real issue is that we keep using linear metaphors for systems that aren’t linear. Software delivery is a dynamic, concurrent set of activities. Tasks feel linear because humans experience time that way, but the system as a whole behaves more like a living network. A dancing landscape that’s constantly adapting, feeding back, and evolving.

Security has to live across that system, moving as the landscape moves, not at one end of it.

You can absolutely optimize within a zone and make developers more security-aware and catch more vulnerabilities early, but that’s local optimization. It doesn’t make the system secure. A secure system is one where all zones are considered and continuously connected. Insights from incidents feed into design. Monitoring informs coding decisions. Security isn’t a phase; it’s a characteristic.

The challenge, then, is not to blindly start trying to shift security left, but to embed it everywhere in zone-appropriate ways. It may have made sense in organisations where security was treated as a final gate, though that, hopefully, is a practice far behind us these days, but thinking linearly doesn’t capture the reality of complex modern delivery. Real security is not about how early you start, but how continuously you adapt. Anything less risks being security theatre — reassuring on paper, but irrelevant to the real-world threats your systems face.

October 14, 2025
How to Prove That Your Security-Aware Developers are a Cut Above the Rest
Security-aware developers are the best first line of defense an organization can have when it comes to software security. They ensure that the code being used in applications is secure from the get-go. They can save countless hours otherwise spent on technical debt, fixing flaws found in code during testing or after release, not to mention the potential costs of lost business, regulatory fines and reputational damage that can result from a breach.

However, the problem for many organizations is that their developers aren’t equipped to ensure the security of the software they are generating. Too few organizations have invested in upskilling developers in secure coding practices, which is a different skill set than required for generating code or building applications. Without the right upskilling program, organizations will continue languishing in the risky world of insecure software.

That is starting to change, as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has launched a global Secure-by-Design campaign that is being echoed in other countries, such as Australia. The goal is to shift the burden of responsibility away from consumers and small businesses on the receiving end of software and place the onus for security on those who produce it. Australia’s Secure-by-Design legislation, for example, pushed for a whole-of-organization approach to security, emphasizing that secure software is a business goal, as well as a security and compliance requirement.

Rather than viewing Secure-by-Design as an additional burden that gets in the way of business, vendors should see this as an opportunity to nail down their security programs, adopting a new standard of secure software excellence, with security-aware developers as a pivotal ingredient.

Companies that need to respond by upskilling their developers should take a three-tiered approach that includes implementing a measured program to deliver education and competency, providing right-fit tools that suit the organization’s tech stack, and overhauling the processes that have led to cut corners and insecure coding patterns running rampant.

Provide Meaningful Training (and Measure Progress)

The organizational benefits of secure coding, including greater security and productivity, are apparent. Still, developers also have incentives to acquire security skills, including higher salaries, the opportunity to work on more prestigious projects and greater job satisfaction with less rework.

But developing software and doing so securely has been, to date, two different things. Software security is an area where colleges and universities have notably fallen short. CISA recently called universities on the carpet for overlooking secure software, saying the schools were “producing a software developer workforce that enables increasingly damaging cyberattacks.” Of the country’s top 24 computer science universities, only one requires cybersecurity in its curriculum, CISA said. For the other 23, it is an elective.

While higher education institutions may get on board with secure coding as part of CISA’s Secure-by-Design campaign, the upshot for companies right now is that developers must learn on the job.

Enterprises should upskill developers, measure their progress, prove that they’ve acquired the necessary skills and reward them as part of a holistic approach to reducing risk. There are three tiers to the upskilling process:
- Education: Upskilling developers require an agile, interactive learning program that provides the training they need and fits their schedules and work environments. A program should be available in multiple formats, involve hands-on training on the types of real-world instances they are likely to encounter and include benchmarks to measure progress.
- Right-fit Tools: The training should fit the environment developers work in. For example, they should involve the programming languages that developers use and the tools relevant to their jobs.
- Overhauling Processes: Secure code must become a part of a company’s culture, a business priority as much as a security priority. Organizations can ensure that secure software is ingrained in the environment by producing secure code at the beginning of the software development lifecycle (SDLC) and continuing to test and remediate flaws throughout the lifecycle.
Providing the training is one thing, but organizations must be sure that it sticks, that is, developers have absorbed the training and know how to apply it. Organizations can use an automated, data-driven assessment of the development team’s secure coding skills as part of the benchmarking process.

A trust score measures individual progress while aggregating overall progress to assess the AppSec team, identifying top performers, average achievers and those who need more help. Combined with benchmarking metrics, organizations can evaluate the effectiveness of upskilling programs both within the organization and compared with industry benchmarks and best practices. It highlights areas to optimize in the process of creating a high-performing and secure development team.

To further add context and gain complete visibility into how upskilling is reducing risk to the enterprise, organizations can make use of a trust agent, which ties AppSec training to specific developer code commits. An agent will provide information on who made commits, the language they worked in and their security knowledge and skills. That information is presented in dashboards, offering insight into how well development teams’ security competencies and code commits are aligned across the organization.

A trust agent can also incentivize skill development and gatekeep sensitive repositories and prestigious projects until skills verification and benchmarks are met.

Security From the Start With a Data-Driven Approach

In today’s fast-moving AppSec environment, creating secure code at the beginning of the SDLC is no longer something nice to have; it is essential. Developers are producing more code than ever before, and vulnerabilities can appear in live code faster than security teams can identify and remediate them.

Organizations need their developers, working with security teams, to ensure code is secure at the beginning of the development process, whether they are writing the code themselves, using code generated by AI assistants, or applying open-source snippets acquired from a repository.

But they need good training to do that, and companies must ensure that developers are applying what they have learned. A comprehensive, agile upskilling program, backed by data-driven benchmarks to prove that training is getting accurate and impactful results, is the key to lowering organizational risk. It incentivizes developers to gain the secure coding skills they need while setting a new standard of secure practices and compliance for the organization.
January 27, 2025
From Reaction to Robots: Riding the AI Wave in 2024

As we navigate another year of consistent zero-day breaches, legislative pivots, the explosion of AI tooling and threat actors growing bolder and more desperate, it’s safe to say that getting comfortable with change is a requirement for thriving in the technology industry.

We occupy a notoriously unpredictable space, but that’s half the fun. Compared to many other verticals, technology—especially cybersecurity—is relatively youthful, and the future should be something we can all look forward to blossoming in sophistication alongside the technology we swear to protect.

So, what can we expect in the industry in 2024? We put our heads together, looked into our crystal ball, and these were the results:

Government Regulations Around AI Will Turn the Industry Upside Down

It was the talk of the conference circuit in 2023, with several high-profile presentations at Black Hat, DEF CON, Infosecurity Europe and many more warning of the explosive changes we can expect from AI implementation across every industry, especially cybersecurity. As tends to happen with low barriers to entry for such transformative technology, adoption has outpaced any official regulation or mandates at the government level.

With significant movements in general cybersecurity guidelines and benchmarks around the world, including CISA’s Secure-by-Design and -Default principles in the U.S. and similar initiatives from the UK and Australian governments, it is essentially a foregone conclusion that regulations around AI use will be announced sooner rather than later.

While much of the debate surrounding the mainstream use of AI tooling and LLMs has centered around copyright issues with training data, another perspective delves into how AI is best used in cybersecurity practices. When it comes to coding, perhaps its most human quality is its similar hardship in displaying contextual security awareness, and this factor is deeply concerning as more developers are adopting AI coding assistants in the construction of software. This has not gone unnoticed, and in a time of increased scrutiny for software vendors adopting security best practices, government-level intervention certainly would not surprise.

… And Demand for AI/ML Coding Tools Will Create a Need for More Developers, not Less!

Much has been written about the AI takeover, and for the better part of a year, we have been subject to a plethora of clickbait headlines that spell doom and destruction for just about every white-collar profession out there, and developers were not spared.

After months of speculation and experimentation with LLMs in a coding context, we remain entirely unconvinced that development jobs are at collective risk. There is no doubt that AI/ML coding tools represent a new era of powerful assistive technology for developers, but they are trained on human-created input and data, and that has rendered the results far from perfect. Perhaps if every developer on the planet was a top-tier, security-minded engineer, we might see genuine cause for concern.

However, just as the average adult driver vastly overshoots their ability (notice how everyone says they’re a great driver, and it’s always other people who lack skill? That’s a classic example of the Dunning-Kruger effect!), so too does the development community, especially when it comes to security best practices. According to one Stanford study into developer use of AI tooling, it is likely that unskilled developers using this technology will become dangerous. The study claimed that participants who had access to AI assistants were more likely to introduce security vulnerabilities for the majority of programming tasks yet also more likely to rate their insecure answers as secure. This poses a significant issue; poor developers will be enabled to introduce security issues faster, and if anything, this will only increase the need for security-skilled developers with the knowledge and expertise to code securely and use AI technology safely.

We Will see Consequences for Software Vendors who Don’t Ship Secure Code

CISA director Jen Easterly has made it abundantly clear that software vendors should not be permitted to “pass the buck” when it comes to security within their products, highlighting that the current responsibility for software safety is largely passed to the consumer.

We have agreed with this view, and we believe it will take a shakeup of this magnitude to move the needle toward code-level security—not to mention appropriately educating developers—to be taken seriously.

While CISA’s powers only extend so far—essentially, they can only enforce secure-by-design practices to vendors that sell to federal agencies—this still presents a new security benchmark to hit for many large software vendors. Colonial Pipeline, SUNBURST and, more recently, the MOVEit data breach are all large-scale cyberattacks that affected government-level systems at some point, and with these new guidelines in play, there is a real possibility that future highly visible breaches will receive greater scrutiny and reprimand.

Reactive Security Will Start to be Seen as Old-School

As the goal of increased cyber resilience continues to dominate cyber strategies across multiple verticals, those who rely on reaction and incident response as the only core tenets of their plan will find themselves in a place of unacceptable exposure and risk.

Security professionals must act swiftly in the face of adversity and outright attack, but modern times call for modern solutions, and we simply cannot afford to take a less-than-holistic approach. “Shift left” needs to be more than a rapidly aging buzzword; code-level security should be prioritized, alongside upskilling and verifying the competence of the developers working on the software and critical digital infrastructure we take for granted. After all, who wants the security program equivalent of an Etch-a-Sketch when they could have an iPad Pro?

Now, more than ever, governments and enterprises alike must commit themselves to a preventative, high-awareness security program in which every member of staff is enabled to share responsibility. It’s not enough to cite the cybersecurity skills gap as a reason for falling behind; investment in security-aware developers and fostering collaboration between them and their AppSec counterparts should be a driving force in remaining as secure as possible, both as an organization and within the production of software.

Matias Madou, co-founder and CTO at Secure Code Warrior, contributed to this article.

January 10, 2024
Where to Start With Secure Design – Tips for Developers

Designing secure software is an increasingly hot topic, and for good reason. In recent weeks, we’ve seen a global effort from governments and cybersecurity agencies to encourage security by design through new guidance and changes to procurement rules. During the G7 in May, the QUAD nations (Australia, India, Japan and the United States) released a set of Joint Principles for Secure Software. In the U.S., there are even plans for legislation to make software makers liable for the security of their products. The need for software to be made secure at the design phase has been spotlighted further by recent cybersecurity incidents such as the hack by ransomware group CLOP that exploited flaws in MOVEit software.

But secure design is not a part of every developer’s skill set, and it’s not on the syllabus of every coding course. If you’re brilliant at writing code and keen to know more about how you make that code secure, where do you start?

Here are five tips from former DevSecOps and threat modeling engineer Fraser Scott, now IriusRisk’s VP of product:

1. Get to Know the Threats

To be able to design secure software effectively, you need to understand the threats. A great starting point is the OWASP Top 10. OWASP aims to identify the most critical security risks to web applications. Top of that list is broken access control, and insecure design itself sits at number four. Understanding the biggest risks is the first step towards mitigating them in software development.

2. Try Threat Modeling

The foundation of secure design is threat modeling, which is the process of identifying and mitigating plausible security threats. In its simplest form, this is about looking at your software design and asking Adam Shostack’s four questions:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

The OWASP Top 10 gives you a sense of what the risks might be, and threat modeling is the process of identifying them in your design. See if any of those top ten risks might impact your design, consider what could go wrong and work out what you can do to mitigate it. Before you start writing any code, consider whether you’ve done a good enough job to make the software secure. The sooner you find design issues, the cheaper and easier they are to fix.

3. Connect With a Community

There are plenty of communities of people out there grappling with the same challenges that you are. Experts in security and threat modeling and developers are coming together to discuss and try to solve some of the key challenges in secure design. One such community is Threat Modeling Connect, where people use the forum to share ideas and discuss issues. Experts also host webinars and write blogs. The community also held its first-ever conference in October. There is also a community dedicated to threat modeling on Reddit, and the OWASP Slack has a #threat-modeling channel.

4. Experiment With Automation

Companies who are developing software on a large scale use tools to automate the threat modeling process. IriusRisk makes a community edition of its automation tool available for free, for life, to people who want to give threat modeling a try. As someone who is starting out in secure design, using a tool like this, which generates many of the relevant threats and countermeasures for you, is a great way to experiment with your first threat models. And we’re not the only ones; you can also use the OWASP Threat Dragon and Microsoft’s Threat Modeling for free.

5. Build a Library of Secure Code

One shortcut to secure design is using existing secure design patterns and road-tested components. As you develop software, keep a library of secure code that has been threat-modeled and scanned using application security testing tools that you can return to in the future. The Threat Model Cookbook on Git Hub has some sample threat models you can use as a starting point.

November 17, 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
Standardizing a Process that Drives Secure-By-Design

In “Building Security into Code + Culture,” I described how our culture of coding is predicated on chaos, and the critical challenge for organizations is to establish the right mix of processes and tools that support a smarter, risk-based approach to development. A key aspect of this strategy is, of course, to implement a sense of order within the chaos that enhances security without hindering the speed of innovation.

I overviewed a number of different recommendations to approach secure by design, such as making code more mature and baking in security measures and privacy/contractual compliance from the start. I also emphasized that organizations should tackle the rules, tools and fears pillars that help shape the culture, as each of these can be transformative in helping people use the right approach or method. Making the rules and defining fears is relatively straightforward, and with the right degree or training and awareness your organization can adapt.

But what about tools? The right tools can do wonders to “force” people to use better, smarter, more secure methods—that is, if such tools exist. Though I have not done a deep dive into whether there are any robust development tools integrated with security software, I’m a realist and will go out on a limb to say none of them have reached maturity just yet. In light of this, it’s essential that organizations focus on standardizing the overarching process that will enforce privacy and security by design, development and deployment.

The first thing to do is set the business drivers behind the process from a legal standpoint. Gather and research the privacy regulations and compliance requirements that affect your organization. Analyze and then translate these using a risk-based approach to security controls requirements, and then publish these as an awareness catalogue available to all developers across your organization. You should also ensure that training is available, on-demand and on a just-in-time basis, for any developer on any desired control.

Next, set the technology drivers by prescribing to secure coding practices defined by the industry, such as the Web Application Security Consortium (WASC) – Threat Classification system (based on Open Web Application Security Project [OWASP] Top 10) and SysAdmin, Audit, Network and Security (SANS) Top 25 (which are based on the Mitre – Common Weakness Enumeration [CWE]).

At this point, you must ensure that all your applications and systems comply with the security controls requirements catalogue you created. These can be batched into smaller parts that are handled by developers or teams of developers, all of which use your security controls requirements catalogue and industry-standard secure coding practices. Again, you’ll want to make sure that training sessions are available on a just-in-time basis for any developers who need them!

Upon completion of each section or unit, code must be validated and verified for trust. Peer code review is the first step—have your developers present their work and provide the logic to a different team of developers. You can always employ static code analysis to scan code for any weaknesses, defects or violations of best practices, and subsequently enter the bug fix stage if any are detected.

Then, you can merge the code branches into the main and compile for run time, so you can conduct live vulnerability scanning and penetration testing. Again, these should be based on the industry-standard secure coding practices adopted across your organization. At this point, you should be able to establish reasonable assurance for the release version of your application or system by having published artifacts for review by entities such as auditors or clients.

Continuous improvement will require adding new features and subsequent emphasis on the validation and verification process. I would also recommend repeating the entire process from start to finish on a regular basis to reinforce the process, perhaps annually or semi-annually. And of course, if there are any major changes or shifts (as there are likely to be) in your privacy regulations, compliance requirements or secure coding practices, this will absolutely need to be addressed at the organizational level so your process addresses these head-on.

Privacy and security are such important topics today because they are an artifact of the youth of the computer software industry. If this industry was more mature, then the outcome would be quality code. For some reason, it’s okay to create buggy, weak and inadequate software in a world in which we wouldn’t tolerate buggy, weak or inadequate cars, airplanes, bridges, buildings … and the list goes on. And the reason for this is pretty obvious: People are acutely aware that cars, airplanes, bridges and buildings put their very lives on the line, whereas software “just” makes them susceptible to things such as identity theft and ransomware.

This is the message we’re sending: It’s not OK to kill people, but it’s perfectly acceptable to ruin their lives. This is not OK! It’s time for organizations to standardize the processes that drive secure-by-design, and embrace necessary and fundamental changes to how we approach development. As developers and IT professionals, the onus is on us to shape a better world driven by quality software.

About the Author / Robert Hawk

Robert Hawk is Resident Security Expert at xMatters. He has extensive experience in Information Systems Security, Computer Security, Cyber Security, Information Assurance, as well as Governance, Risk, and Compliance (GRC) Management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI, and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on LinkedIn.

October 31, 2017