Recording date: May 3 and 8, 2021

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

In a private Twitter chat, Nick and Kenn White, who leads applied encryption engineering in MongoDB, were discussing tech debt burndown, and Kenn mentioned that Mongo maintains an entire team to remove distractions and handle barriers to engineer happiness. So this episode, Kenn joins Chris and Nick to talk about that, because Chris had been mentioning enabling teams in the past couple of episodes.

Mongo recognized that when something takes one person two or three or four hours of frustration, that’s real money when you’re talking about three or four or 500 engineers. The Developer Productivity Team at Mongo set out to assure that everyone has on day one a fully functioning and configured Linux laptop, with all the tools, libraries, permissions, etc., that they will need on day one. This includes wikis and internal resources.

That “get out of the engineers' way” approach is what Chris has been describing, and this is a real life example. Kenn mentioned 10,000 to 20,000 hours of testing on every build, so it’s expensive if a build fails. The way Mongo has approached this supports that kind of environment. This extends down to “I can’t make Ruby 3.6 work on this particular Linux flavor” and the enabling team will tackle those kinds of problems.

But when we sought answers on metrics, they seem to elude Mongo as much as anyone else, saying that metrics are divorced from real productivity; Kenn boils doing what works down to what makes engineers happy. That’s not a bad metric. He says that the trick for his teams has been post mortems on every major project to find the tar pits and management pains in the butt, the lack of approvals (he puts a lot of emphasis on getting expense reports reimbursed quickly, which is another one we like), etc., and those lessons are iteratively applied.

The group began to follow a thread that had begun pre-show, about Kenn’s early jobs re-factoring cardiac monitoring software, but went off on a tangent that, while interesting (to us), was off topic. Which is where the quote about monkeys nesting in the satellite dishes, above, came out (it was a story about on-the-ground realities in an African networking project).

But Chris and Nick were very interested in medical device manufacturing issues: if you’re in an industry that is heavily regulated to the extent that you can’t make changes to anything once launched, and at the same time, the industry makes machines that can spend decades in the doctors' offices. How do you avoid tech debt if it is almost mandated by the law?

To answer this, we brought in Bill Pelletier, who has tons of experience in exactly this area.

Bill sets out a recent history of medical device manufacturing from custom hardware and waterfall processes through Software as a Medical Device and today’s builds. Once you peel back the fancy, shiny cover from a computerized tomography (CT) scanner, you are going to find commercial off the shelf, hardware, nothing special about it, and in many cases it is running off-the-shelf software operating systems, which is fine right up to the moment you put a network jack on it.

That gets us into the meat of the problem: testing systems for these devices are designed for these big monolithic, all-encompassing, “test everything” processes which just doesn’t make economic sense in the new paradigm. Enter, over the past five or six years, the Software as a Medical Device. No longer constrained to this older hardware model, we were one step closer to more readily available software updates, using agile methodologies - but the testing regimes are still a huge barrier. This has led to the rise in recent years for calls for better software bills of materials, and pushes to require manufacturers to identify every software component with a standard taxonomy so that users can know immediately what’s inside.

THe discussion turns to the realities of this struggle to balance security and software concerns with those of patient safety that, ironically, is often better maintained sticking with the known state - as in many critical environments, the bias is toward saying with the known good because the cost of being wrong is so high.

Recording date: May 1, 2021

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

Let’s talk about pipeline. Lots of things get improved by building continuous delivery pipelines and then going back to them and iteratively making improvements. But Chris thinks that pipelines themselves can be a place where we accrue tech debt, even at the entry point to those pipelines.

So, Chris has been looking at branching strategies.

If you look at open source development, people agree that trunk based strategies are the way to go, so we’re taking short terms branches or forks off a trunk, but coming back to it quickly. But engineers from an enterprise background have a range of versions across different customers. This quickly runs to vast differences between versions, and lots of tech debt.

What suffers? Updates like security patches, and the engineers, who have to work across a multitude of branches as opposed to being on a constant edge of the trunk version, is pure tech debt.

Nick mentioned that this seems to point back to engineer flow - if your engineers can’t get into the groove because they’ve got no institutional memory and they have to constantly figure out where they are in order to fix things, they’re actually creating tech debt while thy are addressing old tech debt!

It’s interesting to think how we got here, but it’s true that, because people move around the industry, people, Chris notes, often leave a role before decisions they have made have a chance to catch up to them. So, decision logging becomes super important. But outside the code itself, the log and commit log that people add are critical pieces of context for the next people.

All too often, though, they say things like, “Merge to master” or the dreaded, “Fixes”.

After that, the readme and changelogs that go with things should tell a story, but there’s a more macro scale look at decisions people make: what were the tradeoffs that people had in mind when they made their decisions? This is absolutely critical to know. Because when we make decisions, thinking we can back out of them< we sometimes find ourselves in architectural cul de sacs.

The conversation turns to Type 1-Type 2 decisions which Jeff Bezos began to discuss back in 1997. Nick gives as an example of what’s intended to be a reversible decision the log pipeline that his teams are working on. Chris Mentioned that pipeline engineering may seem to be less worthy work done, but Chris and Nick both feel that pipeline enabling work is among the most important in an organization.

In carrying on the new tradition of references related to what we’re discussing, Chris comes up with two important areas of research: James Governor’s work on RedMonk about Progressive Delivery, and Netflix’s work on Chaos Engineering.

Nick mentioned also the SLSA: Supply-chain Levels for Software Artifacts proposal, which is an amazing project available now on GitHub. The SLSA (pronounced ‘Salsa") project is “inspired” by how Google does things (and has been at least updated by at least some people who work at Google), and ultimately will have a full set of standards, a catalog of technical controls, and a process for accreditation - but for now it’s a diabolically useful set of principles and definitions that are really worth a lot of time.

One major point of the project is to be able to know and be certain about the provenance of code at every stage of the pipeline - at the very least to be able to attest to the sanctity of code, but also to, say, stop unauthorized people from being able to insert code into codebases (Heloooooo, Codecov Hackers!). Nick and his colleagues have begun to use SLSA as a great way - at a very minimum - to agree on a taxonomy and lexicon, and as milestones on their journey. Chris and Nick agreed that SLSA should be an episode in its own right, hopefully with a guest involved in its management to discuss it (hint, nudge, wink).

The episode concludes with a pivot to a blog post by Signal’s Moxie Marlinspike who took on the mobile device forensics company Cellebrite. Cellebrite had earlier claimed it had “broken” Signal encryption, which was utter balderdash. In the information security community, the document quickly was called the Moxie Manifesto but it should be read as nothing short of a declaration of war against Cellebrite. Cellebrite customers (like law enforcement) are casualties of the war.

Moxie shot back with what may be mistaken for a lighthearted report but which is both ruthless and credible based on his demonstrated exploitation of a Cellebrite box:

Chris and Nick were both very interested by the manifesto and think it will be have a long tail.

Recording date: March, 2021

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

How do you measure technical debt? What are the metrics you use?

Chris hasn’t found the magic formula. Over the past few years Chris has been acutely aware of the quote from Accelerate about not trying to inflict metrics on people before the culture change happens, they’ll game the metrics. Nick agrees, and also says he has the basic problem that coming up with the right metrics is hard.

They agree that time is a really bad one: trying to quantify tech debt around the time you spend on it actualy doesn’t work (though it’s not worthless).

Some organizations build a bit of burndown into every sprint, but Chris isn’t seeing that widespread - but Nick says that after about a year, his shop is finding ways to do just that.

It took a year of seeing the results of concerted bursts of burndown, and a company-wide Objective and Key Result (OKR) on Trustworthiness. One challenge he has is that it’s hard to tie in the minds of senior executives information security (which is what Nick does) to availability and scalability as opposed to firewalls. But his colleagues are making great progress.

Nick thinks the most useful thing he’s done in the past year is to embed engineers, developers, SREs and security people into standups as often as possible to try and find the overlapping interests. And that has led to some success around thing together tech debt they need to code around and the performance of engineering squads.

Chris spent a bunch of time recently looking at Chaos engineering and how to introduce it into what they do, but he’s finding that if you’ve not already got to the stage where you can do good quality progressive engineering you’re just not ready to do Chaos engineering. Similarly, Nick thinks that applies to Eng teams that find themselves working harder but not having a commensurate increase in productivity.

What Chris sees in the bottom 50% of companies is related to a Charity Majors comment that they have the engine underwater and they have to work ever harder to see that they need to do something to drain the water that is flooding you.

(i feel like that explains the lower 50% of the dora report 💔 they are bailing water out of the boat with all their might but not as fast as the water is coming in through the holes, so they never get the engine out of where it is submerged and cannot start up) pic.twitter.com/X2Izh53tex

When technical people have to talk to non-technical people about this, people who are smart but don’t see the tradeoffs in feature development, the non-tech people don’t understand the tradeoffs. Not that they don’t want to understand, but that they don’t see it. so the quest for metrics is really about finding Indicators Of Tech Debt.

Chris points out that time is bad as a measure because for engineers, it’s really less about time and more about getting into flow state: is your tech debt preventing flow from happening?

He mentions this is related to cognitive load, and that he’s been following the work of Team Topologies, whose principles Matthew Skelton and Manuel Pais have been spending years with organizations starting the DevOps topologies, finding patterns and anti-patterns and how work flows betwen those teams. They feel teams need to be organized to minimize cognitive load.

It seems to be about putting boundaries around the members of teams so that they can actually apply their brain power to the problem at hand in the context of their work, and Chris thinks we can start to reason is that tech debt is adding a constant cognitive load that everyone has to deal with.

This is a self-inflicted wound: rather than just doing a task, they have to remember oral histories of “when you’re trying to make something in this environment, here are the 24 undocumented things you have to look out for or they will bite you.”

Nick and Chris raise the idea that tech debt is not necessarily just “old stuff” because mainframes are just often not tech debt, because they still work.

Tech debt is more tied to the fragility of environments.

Recording date: December, 2020

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

Chris and Nick welcome their old friend Wendy Nather, Head of Advisory CISOs at Duo Security (now Cisco), to the podcast to discuss her work on the Cisco Security Outcomes Study. Now, technical debt isn’t only about security, but they’re related - and one of this report’s most solid conclusions addresses it specifically.

When Wendy began her work at The 451 Group (now 451 Research), she started asking her CISO friends questions: ‘If you’ve just taken a CISO job at a company that had no security, what would you buy?’ The answers fascinated her. Now at Duo (Cisco), she set out to formalize research that was released as Cisco Secure’s Security Outcomes Study.

Security professionals are great at doing benchmarks, but it turns out that our peers may just be bad at security.

So for this report, Wendy and her team sought a correlation between things we struggle with in security practices, and the outcomes of the programs they run to address those.

The research was completely technology and vendor free. They queried security professionals (using YouGov to run the surveys) from around the world about their security practices across 25 areas, then brought in Wade Baker’s team from Cyentia to analyze the data.

The methodology is actually one of the best things about the report, because it is decidedly, simply put, not bullshit.

The study was double-blind, with 4800 respondents not knowing who was asking, and Cisco not knowing who was answering. The question was, “What appears to correlate between security practices and outcomes?”

As a great study will do, it raises more questions than it answers, but it also is a report that, by applying analytic rigor at the problem, it is just a great report.

Nick points out that there are several issues that security pros take as gospel are just not true. We won’t spoil it but tropes about people who own compliance, people who own apps, security awareness, identification of the top cyber risks … All of these have very interesting real-world correlations to results.

As it turned out, for example, having someone own compliance turned out to not be correlated with better compliance results, but just buying new IT gear raised the likelihood of success in meeting compliance goals by more than eight percent. Other activities correlated with better compliance outcomes included well-integrated tech, timely incident response, having a sound security strategy, and setting deadlines for remediating vulnerabilities… There’s lots more.

Chris points out that this makes sense: those programs mentioned in having a positive correlative outcome are all about reaching across the organization and speaking with people.

Wendy is quite sensitive to the idea that the two practices identified as most likely to correlate to better outcomes, Proactive Tech Refresh and Well Integrated Technology, are of course seen by the more skeptical of us to have been directly driven by the fact that Cisco is a vendor of that stuff. Wendy insists (and Wade has insisted) that the double-blind nature of the survey administration and the analysis means that it actually was independently learned, not sponsored. We believe it. Wade tweeted about it recently:

2/2 My answer is always the same: A third party survey firm fielded the study, respondents didn’t know Cisco sponsored it, and @cyentiainst did the analysis to obtain that funding. I’m sure they like the outcome but they didn’t influence it. Get the study: https://t.co/ffYkfyhrf1

Also, the survey didn’t ask, ‘Do you think buying new stuff makes stuff better?’ they asked separate questions. The correlations were stronger than they thought.

But Chris happens to think that a lot of this is hogwash. Chris thinks that, as an example, tech refresh is already built in to the market (because virtualization and cloud), but Nick points out that Chris has lived five years in the future as long as Nick has known Chris, which is 16 years. He said that Chris, Wendy, and Nick have been very lucky, but that most people don’t have the ability to have contemporary kit and work in environments where spinning disks are still the norm.

Nick also pointed out that “IT Refresh” is unclear - do we mean servers and firewalls, or laptops and printers? And Wendy pointed out that the questions were in fact vague: we don’t know whether the question means any or all of those things. Which supports the idea that a tech vendor didn’t put its thumb on the scale for this question.

Chris speculates that people who feel good about their company will say more positive things here. And there is a real discussion about whether shinier MacBooks help with talent retention and compliance success.

Wendy says that some of this seems obvious, but some isn’t. How getting sufficient budget helps with executive buy in may well be a circular argument.

Or take Identify Top Cyber Risks. That feels outlandish to Chris, who would have thought it would seem that identifying the top risks you face would be top of the list, and it turns out to be worthless.

We think that the podcast is a good listen (well, we would) and that the report is absolutely worth a read.

We especially like that the report is available to read with no registration required.

Recording date: April 17, 2021

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

This is a common question, and Chris and Nick discovered that they do it differently.

Chris describes how he views tech debt from the perspective of his continuous integration and continuous delivery pipeline: “How quickly can I release, and what’s getting in my way?” He discussed that recently, Charity Majors has been discussing the importance of a quick feedback cycle for developers:

people really do leave their jobs over build times. i am not making this up.

the impact your deploy pipeline has on developer productivity and happiness is HARDCORE. https://t.co/z49xUxXWsk

Basically, this comes down to, ‘you’ve got 15 minutes to build’ in order to be good at this, and this brings us to the Theory of Constraints thing: what things are blocking me from getting to that 15-minute build time, and how do I get rid of them?

Nick says he comes at this from a more traditional infosec approach, basically, how do I get in, how do I move around? Chris points out that this reveals two prevalent schools of thought in the industry when it comes to building software: “How do I make this work?” and, “How do I break this?”

How do we make it work leads to “How do I make this resilient”

Both of these approaches seem to meet up at resilience, which brings us to the broader conversion about software dependencies and dependencies management, which itself is based on the fact that today,

As we go about that process, we need to get open source, and buy tools, and many are pretty janky - and the janky tool is the one that gets you.

Chris thinks there is better tooling coming, and Nick is far more skeptical of that.

This gets into the fact that libraries get poorly maintained or abandoned and can in fact be taken over by malevolent actors, and now a trusted source is pushing malware.

Everyone understands that but to what extent do you have proper insight to what you’re assembling?

Supply chain breaches are top of the pops. But what are supply chain breaches?

Supply chain attacks happen when people get into these dependencies, which are then incorporated, or they get into the build chain to insert software that shouldn’t be there.

They can also be broader than just development operations, attacking necessary business tools that the company uses as a whole.

Probably the earliest great example of this that we remember is the RSA SecureID breach of 2011. Chris remembers that the term Advanced Persistent Threat was particularly bogus, because it isn’t the threat, it’s the attacker that is sophisticated and advanced (Nick throws in a plug for an article he and Scott Crawford wrote in January, 2010 called, ‘It’s The Adversaries That Are Advanced and Persistent')

But there’s been a change in dynamics in the past few years - where it felt like the entire SecureID breach targeted Lockheed Martin, now it feels like “stage the attack first and then choose your targets" rather than choose your target and then stage your attack.

If we are a contemporary software company or even a business, and we’ve done the right thing by outsourcing the stuff that isn’t our core competency, we find that there’s lots of stuff that isn’t everyone’s core competency - email servers, ticketing systems, remote helpdesk.

So even though we all use a much more diverse set of universal tools, each tool in its category is just as much a single point-of-failure as was SecureID - we all use the same instant messenger, the same ticketing system, the same what-have-you, so targeting can be conducted on an industry vertical-level by attacking a tool that horizontally attacks the whole industry.

How do we protect ourselves against these third party risks?

Spreadsheets.

Chris talks about the Hyperscalers like cloud and the starting point of the Shared Responsibility Model in which security and compliance are the shared responsibility between the hyperscaler and the customer.

We’re now at a point where we rely on the Hyperscalers like AWS for security.

Nick points out, though, that AWS has a different idea about what “secure” means from its customers - them being secure is just not the same as us being secure, and Chris rightly points out that this is the other side of the shares security model. But the point of handover is sometimes unclear to the customer.

Many things that should be done are best practices are not enabled by Amazon by default, and this is a huge issue, which Chris points out is completely right and behind the idea that we read the dunderheaded thing of the week every week in Corey Quinn’s Last Week In AWS newsletter.

But if you want the audit trail, you need to flip the bit that starts the taxi meter to fill your other S3 bucket with logs.

In looking at attacks, it’s important to realize that attackers will always seek the path of least resistance as they target you - and often these days the path of least resistance is the tool. Chris mentions another Economics of Information Security Paper, Where Do All The Attacks Go? in which the question is asked, ‘If security is so awful, why isn’t everyone attacked every day?’ and the answer of course is that even attacker groups have bosses to please and budgets to live up to. Targeting is hard.

So the idea to use supply chain attacks being in the news is to use them to justify the time it takes to consider something: given a supply chain attack against our CI/CD tool, what permissions would it have, and how can you follow those permissions throughout your CI/CD pipeline.

All too often we bring in these external tools to cover up what we’re not good at, which would be fine if they were better than they actually are. Threat modeling through a theoretical supply chain breach can help you identify new forms of tech debt.

Recording date: February 6, 2021

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

We had a great conversation with Ian about how he runs a rather different kind of information security operation that can be described as a group of companies reporting up to one security organization for strategy, but which each support their own individual needs day to day.

Ian Amit spent most of his career in information security, with a lot of time on the offensive side. He spent some years as a senior manager at AWS, and in the past few years he has been Chief Security office at Cimpress, which runs a collection of independent businesses whose CISOs report up to Ian, who is kind of the supervisory CSO - this set up is most similar to that of GE’s.

Some of the smaller firms have no CISO, and Ian then serves as their de facto CISO, and the larger brands - most notably including VistaPrint. And Technical debt is primarily Ian’s responsibility - he and Nick have discussed it quite a bit over the years, and Ian was pivotal in a presentation Nick made, Tech Debt Burndown: Kill It With Fire which he presented at CornCon VI: The Return of the Cyber Jedi 2021.

Nick asked about whether there was a difference between security tech debt and technical debt.

Ian thinks Tech Debt is Tech Debt, but that it has a lot of security repercussions.

Accrual of tech debt gunks up the business operation and also opens up the company to additional risk.

Chris observed that old stuff has known vulnerabilities, new stuff might have vulns but only the most sophisticated attackers are going to find the 0days, But in terms of staying atop patching, how much does it relate to testability of the environment?

Ian says that’s something he thinks about a lot - known knowns versus unknown unknowns. He tries to let the business decision guide the way - not to discount security, but prioritization matters. Tech debt by itself is not a problem, it is only one after you view it in the context of how it might affect the business.

It may be OK to carry a certain tech debt indefinitely if it isn’t slowing the business. The exercise is to get the right stakeholders to really understand what they need and what our stack delivers.

Nick was wonders whether Ian was hired with tch debt as a guiding principle, which may mean the executives actually understood this before he got there. That’s rare. And also, what is Ian doing with metrics?

Ian agreed that the executives had a lot of tech debt, lots of companies with different histories - Vista Print is more than 20 years old and Cimpress' newest firm is two years old. They realized this was critical to success and growth. So the executives wanted someone who understood how to harmonize all these varying challenges, and Ian and management realized that technical debt burndown was central to the effort.

Ian’s approach to metrics is an interactive look at what is there and how it’s being burned: both at the tail end (what is there out there that might bite me), and revisit our fresh decisions to be cognizant of repercussions they may have on tech debt accrual.

This jibes with Ian’s quote at the top of the page here, and he added the other quote of his that we love: “Tech debt is not a project; technical debt is a process.”

Ian says he went through the herky-jerky attempt - start fresh, groan on until you can’t proceed anymore, stop everything to burn it down - so often that he realized it just has to be embedded into every sprint.

It can’t just be the security people’s job to chase it down - everyone in DevOps has to embed this into their processes.

Ian would rather talk of code quality than secure code: if our code sucks, it is also fragile and insecure.

Chris raised that some of this is the way we deal with the Red Queen, that it’s a choice between a steady pace, or occasionally stopping for a breather which means we need to run even after we rest.

Ian agrees, and recognizes that we have to adapt to the business needs. We need to run faster than the Red Queen, to run ahead and clear the path, and sometimes to drift behind in case she changes course.

With regard to SSDLC, which requires software development, and people discuss “shift left” - forget that. How do you start the conversation about technical debt before the PRD is done, before the design doc?

Ian refers to lifetime ownership of the code, and when devs understand that they are responsible for the whose lifecycle of the product they tend to make better decisions at the top that will allow them to support what they build throughout its life.

Recording date: December 6, 2020

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

Nick thinks it is the stuff we put off in favor of things we want to do*, while Chris quotes Ward Cunningham and Martin Fowler, summarizing that technical debt is basically the quick and dirty fixes that incur interest payments, and using the concepts of tech debt to describe problems faced over time.

A chat about “shift left” or moving earlier in the SDLC, which boils down to the human factors of tech debt accrual.

Nick mentions a collection of moments in which decisions are made to do the scalable thing or do the fun thing. Chris points out these concepts apply to both Waterfall and Agile approaches, and invokes Paul Downey in his discussion of when decisions get made and how they are addressed.

When should it be addressed? Why do organizations schedule huge tech debt burndowns as opposed to building in TDB to every sprint (Nick quotes, but forgets to credit, Ian Amit, and this quote is covered in Episode 2), and Nick quotes Phil Venables who tweeted that we should measure tech debt in the terms of what percentage of dev time is spent on this.

Which leads Chris to ask about what metrics are right. How do you calibrate information about doing it quick versus doing it right?

From engineering time to executive buy in, these are critical issues. We can’t tell you the monetary value of not scaling a thing, and that is a huge issue.

Chris mentions that one if the issues that arises is what kinds of tech debt do we face? One of the ones he likes to focus on is policy debt, which is a fundamental type organizations face.

This raises the issue of policy over time: in FinServ, most policies were written in the days of the moat and the gate, and they don’t address contemporary, cloud native architectures.

This brings in some of the human decisions we make.

How do we answer questions about the interplay between policy and regulation, like the “should we reset our passwords every 90 days” question.

Chris summarizes the three different global approaches to regulation.

Singaporean: very prescriptive.

Anglo-American: Principle based, broad brush of expectations and relying on audit companies

Swiss: More comparative: an expectation of participants in the marketplace to reach a certain standards.

Nick describes how US auditors are asking more about technical debt management, but they’re not getting highly specific enough to differentiate betwen tech debt and the underlying policy debt which might drive it.

When we told auditors that our main goals in security was to get rid of tech debt and the auditor asked whether I meant ‘security tech debt’ or just plain old ‘tech debt’ - what’s the difference?

Chris then discusses the CIA triad and talks about how we in Information Security seem to have abdicated the ‘Availability’ part, then referred to a 2006 report called Milk or Wine: Does Software Security Improve With Age which is very pertinent.

The discussion moves to tests: is there a vulnerability in the code, but the bigger aspects of debt include such paralysis that they can’t change anything, because they don’t have the test coverage to know whether a fix here will affect something unintended there?

So test coverage and testability must be part of a strategy to address tech debt.

We in the industry are constantly talking “secure by design,” “shift left,” and the like, but what does this mean in practicality? So, if we are starting a software project today, what are we going to do differently now from last year?

Nick describes his firm’s Squad Security Liaison program, which is designed to foster inter-disciplinary teamwork by making introductions between engineers and security people on a regular basis, to encourage interaction and collaboration. It means they know one another before problems exist, so relationships are there when something goes wrong.

This podcast is all about learning!

* Wendy Nather disagrees with “want”.