Speaker 1: Welcome to the deep dive. We're jumping straight into a
Speaker 1: massive topic today, application security.
Speaker 2: Huge.
Speaker 1: Yeah, it can feel like trying to drink from a
Speaker 1: fire hose, right, I mean it's just a quick look
Speaker 1: on Amazon you see something like forty thousand books listed
Speaker 1: under computer security.
Speaker 2: It's staggering. Yeah, and you know that sheer volume can
Speaker 2: leave developers feeling a bit overwhelmed, sort of wondering, Okay,
Speaker 2: where do I even start, especially when you just want
Speaker 2: to build secure applications?
Speaker 1: Exactly what are the absolute must knows? So our mission
Speaker 1: today really is to cut through some of that noise.
Speaker 1: We're diving deep into the foundational security tech that well
Speaker 1: every developer should probably have in their toolkit. We're basing
Speaker 1: this on some great material focused on securing cloud applications. Okay,
Speaker 1: think of this as maybe your shortcut getting to grips
Speaker 1: with what's truly critical, you know, without getting totally lost
Speaker 1: in the weeds.
Speaker 2: Right. The goal is for you, the listener, to finish
Speaker 2: this feeling knowledgeable, feeling confident, not just buried under like
Speaker 2: a mountain of jargon.
Speaker 1: Yeah, exactly, we want to build a strong foundation. What
Speaker 1: are the core challenges, what are the essential tools, the
Speaker 1: ideas the basics of secure development, and we're going to.
Speaker 2: Kick things off by looking at two really fundamental security problems.
Speaker 2: They're key starting points. Making sure our applications talk to
Speaker 2: each other, securing those communication channels, and second, making sure
Speaker 2: all the other software we rely on our dependencies don't
Speaker 2: end up introducing weaknesses.
Speaker 1: Got it. Communication and dependencies good starting points, definitely.
Speaker 2: So let's begin with maybe how our view of security
Speaker 2: responsibility has shifted over time.
Speaker 1: Okay, let's unpack that because security, well, it used to
Speaker 1: feel like it was purely a software thing, didn't you
Speaker 1: worried about bugs in your.
Speaker 2: Code pretty much? But things have really really changed. Our
Speaker 2: sources point out how even the hardware itself, the silicon,
Speaker 2: can have serious flaws.
Speaker 1: Ah, you mean like Specter and meltdown exactly.
Speaker 2: Those were vulnerabilities right down at the chip level, allowed
Speaker 2: one user in a cloud environment to potentially peek into
Speaker 2: another user's memory.
Speaker 1: Wow, that's not a bug in my application code. That's
Speaker 1: that's the foundation it's running on, precisely.
Speaker 2: And what those hardware issues really drove home is that
Speaker 2: security isn't just an app developer problem anymore. It's it's
Speaker 2: a shared responsibility.
Speaker 1: Right, it goes across the entire IT world, from the
Speaker 1: hardware engineers designing chips all the way up to US
Speaker 1: developers writing the app code.
Speaker 2: The material we looked at nails. This calls it a
Speaker 2: mindset shift. It says, regardless of your role in the
Speaker 2: IT world, security is your responsibility. That's a fundamental change.
Speaker 1: Yeah, it really is. And this isn't just some abstract
Speaker 1: concept either. The financial hit from security failures it's enormous.
Speaker 2: Oh, absolutely.
Speaker 1: Our sources mentioned the average cost of a data breach
Speaker 1: back in twenty twenty was nearly four.
Speaker 2: Million dollars four million average.
Speaker 1: And then you see these massive cases like Marriott getting
Speaker 1: hit with one hundred and twenty six million dollar charge
Speaker 1: or ecofax their cleanup cost was reportedly over one point
Speaker 1: four billion billion.
Speaker 2: Yeah, these numbers really show why it's a CEO level
Speaker 2: problem now and why CISOs, the chief information security officers
Speaker 2: have well increasingly high expectations for developers.
Speaker 1: Makes sense, what kind of expectations.
Speaker 2: They're not just looking for code that works anymore. They
Speaker 2: expect you to use all the security features in the
Speaker 2: products you adopt, follow the company's security standards, and crucially
Speaker 2: design and build secure applications right from the start, so.
Speaker 1: Thinking about security from day one, not just bolting.
Speaker 2: It on at the end exactly. And they also want
Speaker 2: developers to be active players in what's called DevSecOps.
Speaker 1: Okay, dev scops, we'll circle back to that one, but
Speaker 1: first let's tackle one of those initial problems, securing communication channels.
Speaker 3: Right.
Speaker 1: Think about a typical app structure. Right, You've got your website,
Speaker 1: maybe mobile apps for Android iOS. That's the front end,
Speaker 1: and then there's a back end, often arrest API over
Speaker 1: HTTP doing all the work.
Speaker 2: That's pretty calm, very common setup.
Speaker 1: Now that communication, it often happens over networks we just
Speaker 1: can't trust implicitly, like public Wi Fi at a coffee
Speaker 1: shop or just the general.
Speaker 2: Internet, absolutely prime territory for attackers. And that's exactly where
Speaker 2: transport layer security or TLS comes into play.
Speaker 1: TLS the lock icon in the browser.
Speaker 2: That's the one. It's the industry standard protocol for encrypting
Speaker 2: data while it's moving between systems. Okay, and the material
Speaker 2: we have hammers this home as a bus practice, place
Speaker 2: zero trust in all networks, including internal secure networks. Use
Speaker 2: TLS everywhere.
Speaker 1: Zero trust, So even inside your own company.
Speaker 2: Network, especially inside. Just because it's labeled internal doesn't make
Speaker 2: it safe. Remember that target breach a while back, Vague
Speaker 2: attackers got in through credentials for the HVAC system, the
Speaker 2: air conditioning. Once inside, they could move around.
Speaker 1: Wow. So TLS isn't just for the outside world. It's
Speaker 1: defense in depth, even internally.
Speaker 2: Exactly, and mastering TLS understanding it is a kim skill
Speaker 2: for developers. Our source mentions will dig deeper into it later. Good.
Speaker 1: Okay, so that's communication. What about the other big starting
Speaker 1: point securing dependencies?
Speaker 2: Right, making sure the software components we didn't write but
Speaker 2: that our applications rely on are secure. This has become
Speaker 2: a huge attack vector.
Speaker 1: Yeah, the whole software supply chain thing. It sounds kind
Speaker 1: of abstract, but the impact, well, we mentioned Equifax earlier exactly.
Speaker 2: That massive breach happened because they didn't patch a known
Speaker 2: vulnerability into patchy struts.
Speaker 1: Which is like a super common Java framework right.
Speaker 2: Very widely used, and that one unpatched library costs them
Speaker 2: potentially over one point four billion dollars.
Speaker 1: Incredible.
Speaker 2: And it's not just about known flaws and old software.
Speaker 2: There was that events stream incident too. What was that
Speaker 2: a malicious back door was deliberately added to a popular
Speaker 2: JavaScript library. It was designed to steal bitcoin from developers
Speaker 2: applications using that library.
Speaker 1: Whoa, so someone actatively poison the well so to speak.
Speaker 2: Correct. It shows even widely trusted open source components can
Speaker 2: be compromised. These supply chain attacks work because modern apps
Speaker 2: is pull in so many external pieces.
Speaker 1: It's kind of mind boggling when you look under the hood.
Speaker 1: The source gives an example. Spring boots starter data JPO
Speaker 1: sound specific with that.
Speaker 2: One dependency pulls in forty five other jar files from
Speaker 2: fifteen different open source projects.
Speaker 1: Forty five each one needing validation, each a potential entry
Speaker 1: point exactly.
Speaker 2: Each one needs to be checked kept up to date,
Speaker 2: which is why staying on top of patches is just
Speaker 2: non negotiable.
Speaker 1: So how does that work in practice? A vulnerability gets.
Speaker 2: Found right a cve a common vulnerability and exposure gets published.
Speaker 2: Then the companies making vulnerability scanning tools update their databases. Okay,
Speaker 2: your company's scanner picks it up, maybe alerts the development team.
Speaker 2: Ideally you have automated systems that can test and apply
Speaker 2: the patch quickly.
Speaker 1: How quickly are we talking?
Speaker 2: The goal should be honestly, ours, especially for critical vulnerability,
Speaker 2: is you want to close that window of opportunity fast,
Speaker 2: and importantly, don't just scan fix the issues, prioritize the
Speaker 2: ones that are easily exploitable or would have the biggest impact.
Speaker 1: Right. Not all vulnerabilities are created equal, definitely not. But
Speaker 1: you know, patching quickly only works if your application can
Speaker 1: be updated easily. Our source had a cautionary tale about that.
Speaker 2: Ah. Yes, the twelve year old Java library.
Speaker 1: That's the one A mission critical app got stuck on
Speaker 1: this ancient library. Why because the original developers had written
Speaker 1: over one hundred thousand lines of code directly against the
Speaker 1: library's internal private APIs things not meant for public.
Speaker 2: Use, oh, digging into the internals exactly.
Speaker 1: So when the library maintainers changed or removed those internals
Speaker 1: in later versions, which they have every right to do,
Speaker 1: upgrading became this monumental, practically impossible task.
Speaker 2: So they were just stuck on an insecure, outdated version.
Speaker 1: Precisely, it's a huge lesson. Stick to the public documented
Speaker 1: interfaces of libraries. It's not just good coding, it's fundamental
Speaker 1: for security maintainability.
Speaker 2: Makes perfect sense. Let the library manage its own internals.
Speaker 1: And the source offers a clear best practice here, use
Speaker 1: a dependency vulnerability scanner, rapidly fix issues, stay up to date,
Speaker 1: champion these tools.
Speaker 2: It also mentions githubs depended.
Speaker 1: On Yeah, as a good often free tool that can
Speaker 1: help automate standing and even create pull requests for updates.
Speaker 1: Very useful.
Speaker 2: Okay, so securecom secure dependencies. Now let's touch on that
Speaker 2: term you mentioned earlier, dev secops.
Speaker 1: Right, dev secops. It sounds a bit like a buzzword,
Speaker 1: maybe a little bit.
Speaker 2: Yeah, but there's a really important shift happening underneath it.
Speaker 2: Traditionally you had these separate silos, right div build stuff, ops,
Speaker 2: run stuff, security, review stuff often late in the game.
Speaker 1: Yeah, the security gate at the end that often says
Speaker 1: no right when you want to.
Speaker 2: Ship exactly, and that whole handoff process. Yeah, it leads
Speaker 2: to delays, cost overruns, frustration, and frankly, often less secure
Speaker 2: applications because security becomes an afterthought or a bottleneck.
Speaker 1: It sounds like a recipe for friction. Devs feel blocked,
Speaker 1: ops get stressed. Security feels like the bad guy totally.
Speaker 2: So devsekops is basically a movement to break down those walls,
Speaker 2: integrate security into the development life cycle from the very
Speaker 2: beginning all the way through deployment and operations.
Speaker 1: Shifting security left they call it sometimes that's the idea.
Speaker 2: It's about collaboration, shared responsibility, automating security checks within the
Speaker 2: developer workflow. The goal is faster, more efficient delivery, and
Speaker 2: better security, not one or the other.
Speaker 1: And companies are actually investing in this.
Speaker 2: Heavily, both in tools and in transforming their processes in culture.
Speaker 1: Okay. And part of this is developers understanding the rules
Speaker 1: of the road, the security standards.
Speaker 2: Absolutely. That's where the corporate information security team usually comes in.
Speaker 2: They set the standards, the policies. Developers need to understand
Speaker 2: why those standards exist and work with security teams, not
Speaker 2: against them.
Speaker 1: Collaboration not conflict.
Speaker 2: That's the ideal. So with that collaborative spirit, what are
Speaker 2: some of the core security technologies that dev and offs
Speaker 2: teams really need to get comfortable with?
Speaker 1: Okay? The essential toolkit? What's number one?
Speaker 2: Well, given our chat about networks, it has to be
Speaker 2: transport layer security TLS. You just have to encrypt data
Speaker 2: in transit.
Speaker 1: Non negotiable basically pretty much.
Speaker 2: And closely related is the Advanced Encryption Standard AES.
Speaker 1: AES for encrypting the data itself exactly.
Speaker 2: Our source rightly calls it the most widely deployed algorithm
Speaker 2: for encrypting data, whether it's moving or just sitting stored somewhere.
Speaker 2: You find it everywhere, including inside TLS.
Speaker 1: Got it, TLS for the pipe, AES often for the
Speaker 1: stuff inside. What else?
Speaker 2: You really can't talk TLS without talking x point five
Speaker 2: zero nine digital certificates.
Speaker 1: Certificates Those seem complicated, They can.
Speaker 2: Be, but think of them as digital ID cards. They're
Speaker 2: essential for TLS to work, verifying the identity of servers
Speaker 2: sometimes clients too. They pop up in lots of security protocols.
Speaker 1: So that's how my browser knows it's really talking to
Speaker 1: my bank's website.
Speaker 2: That's a big part of it. Yeah, these three TLS
Speaker 2: AES x point five zero nine, they're built on deeper
Speaker 2: crypto algorithms, but understanding these is crucial for developers.
Speaker 1: Okay, foundational tech. Now let's switch to users. How do
Speaker 1: they get into our apps? Authentication?
Speaker 2: Logging in right and for ages that meant usernames and passwords.
Speaker 2: But as our source points out, that model is well,
Speaker 2: it's pretty.
Speaker 1: Broken, broken how security wise?
Speaker 2: User wise, both really security wise. People use weak passwords.
Speaker 2: They reuse passwords across sites. Yeah it's a nightmare. Yeah,
Speaker 2: I know I shouldn't, but we all do it. And
Speaker 2: for users it's just a massive headache remembering dozens of
Speaker 2: complex passwords constantly doing resets. It's bad ux.
Speaker 1: Okay, so passwords are bad. What's the alternative?
Speaker 2: Single sign on or SSO is a major improvement, and
Speaker 2: it's about more than just not storing passwords in your app.
Speaker 1: How does SSO work?
Speaker 2: Basically, it centralizes authentication. Users log in once to a
Speaker 2: trusted identity provider and then they can access multiple applications
Speaker 2: without logging in again each time time.
Speaker 1: Ah, like using your Google account to log into other services.
Speaker 2: That's one common example. Yeah, think about the ACME shoe
Speaker 2: company example. In our source, they have customers, employees, partners,
Speaker 2: all needing access. SSO streamlines that for everyone.
Speaker 1: Okay, so let's take Acme's groups. How do they handle
Speaker 1: customers buying shoes online?
Speaker 2: For customers, the source highlights two main approaches. One is
Speaker 2: exactly what you said, letting them use existing third party
Speaker 2: accounts via protocols like OOF two or open id connect.
Speaker 1: Google, Microsoft, Facebook, Apple, Those buttons you see everywhere exactly.
Speaker 2: It's convenient for users, no new password to create, and
Speaker 2: it shifts the burden of storing credentials securely to those
Speaker 2: big providers who specialize in it.
Speaker 1: What's the difference between OF two and open id connect
Speaker 1: They often seem used together.
Speaker 2: Good question of two is primarily about authorization, granting permission
Speaker 2: for one app to access some data in another. Open
Speaker 2: id connect builds on top of o F two to
Speaker 2: add the authentication layer verifying who the user actually is.
Speaker 1: Okay, subtle but important distinction. What's the other customer approach mentioned?
Speaker 2: The other really interesting one is passwordless biometric login using webothen.
Speaker 1: Passwordless using like fingerprints or face.
Speaker 2: ID, precisely your phone or laptop hardware. Weboten is a
Speaker 2: web standard that lets websites use those biometrics for login,
Speaker 2: completely ditching the password in many cases.
Speaker 1: Is that widely supported now?
Speaker 2: Yeah, Support is pretty broad across modern browsers and platforms.
Speaker 2: You can even try a demo at webothon dot io.
Speaker 2: It's quite slick.
Speaker 1: A passwordless future sounds nice. Okay, what about acme's employees?
Speaker 1: Different needs there?
Speaker 2: Definitely for employees, especially in larger companies. Microsoft Active Directory
Speaker 2: or AD is super common. It's the system managing their
Speaker 2: work logins.
Speaker 1: Right for their laptops internal sites exactly.
Speaker 2: But employees also need access to external cloud apps sauce
Speaker 2: tools right like Salesforce or Slack or whatever. Sure, the
Speaker 2: goal with SSO here is for employees to use their
Speaker 2: familiar AD username and password to get into those external
Speaker 2: apps too, and critically, for ACME to centrally manage access,
Speaker 2: disable an account once when someone leaves.
Speaker 1: One identity to rule them all from the employee's perspective,
Speaker 1: and easier management for ACME.
Speaker 2: That's the idea.
Speaker 1: What about the third group? Acme's partners, like suppliers.
Speaker 2: Partners are interesting. One way is just creating accounts for
Speaker 2: partner employees in Acme's own system, like pseudo employees.
Speaker 1: But that sounds like a management headache when people leave
Speaker 1: the partner company.
Speaker 2: It absolutely is. A much better and more secure way
Speaker 2: is to delegate, use something called federated identity delegate. How
Speaker 2: Acme's ssosystem trusts the partner's ssosystem. When a partner employee
Speaker 2: tries to log into an ACME resource, they get redirected
Speaker 2: to their own company's login page. To authenticate.
Speaker 1: Huh, so the partner manages their own people's access exactly.
Speaker 2: If someone leaves the partner, the partner disables their account
Speaker 2: and their access to ACME systems is automatically revoked. Too
Speaker 2: much cleaner, much more secure.
Speaker 1: That makes a lot more sense now. The source also
Speaker 1: brought up phishing attacks a huge.
Speaker 2: Problem, massive and getting more sophisticated. The example they gave
Speaker 2: was chilling the.
Speaker 1: One targeting Joe Smith, the DevOps engineer at ACME.
Speaker 2: Yeah, he gets an email looks totally legit, supposedly from
Speaker 2: Google Cloud warning about an issue.
Speaker 1: Urges him to click a link, standard fishing tactic.
Speaker 2: Right, but Joe's tired, maybe rushing, clicks the link, gets
Speaker 2: a perfect imitation of the Google login page. Oh dear,
Speaker 2: enters his username password, even enters the code from his
Speaker 2: authenticator app, gives the attackers everything. Wow.
Speaker 1: So even multi factor authentication isn't foolproof against a good fish,
Speaker 1: not if.
Speaker 2: The user is tricked into giving the credentials, including the
Speaker 2: MFA code, to the fake site. That's why phishing resistant
Speaker 2: authentication is so vital. Like what technologies like web often
Speaker 2: which we mentioned, and physical security keys like UBI keys.
Speaker 2: These methods cryptographically bind the log into the legitimate site,
Speaker 2: making it incredibly hard for phishing sites to intercept useful credentials.
Speaker 2: So the takeaway for developers is externalize authentication, use a
Speaker 2: dedicated SSO service, rely on modern secure protocols like OOF
Speaker 2: to open idconnect, and especially push towards phishing resistant methods
Speaker 2: like web Often. Don't try to build all this yourself.
Speaker 1: Okay, that's user login covered. What about the secrets? Are
Speaker 1: applications need apikeys, database passwords, that kind of thing. Where
Speaker 1: should they.
Speaker 2: Live application secrets? This is critical. The absolute worst place
Speaker 2: is directly in configuration files checked into source control.
Speaker 1: Yeah seems obvious, but I bet it still happens.
Speaker 2: All the time. The huge risk secrets get exposed. They're
Speaker 2: hard to rotate regularly, which you absolutely should do, and
Speaker 2: there's no audit trail of who accessed them.
Speaker 1: So what's the right way.
Speaker 2: Centralized credential storage. Think of it as a secure vault
Speaker 2: just for your application secrets, like.
Speaker 1: A password manager, but.
Speaker 2: For apps kind of Yeah, the source mentions different types.
Speaker 2: You've got services from the big cloud providers as your keyvault,
Speaker 2: awskey Management Service, CAMS, Google Cloud, KMS, very convenient. If
Speaker 2: you're already in that cloud, then there are options tied
Speaker 2: to container platforms like credhub for cloud Foundry or Kubernety.
Speaker 1: Secrets makes sense if you're using containers.
Speaker 2: And finally self hosted options like Hashi corp vault, which
Speaker 2: you run yourself.
Speaker 1: Lots of choices, but the core idea is the same,
Speaker 1: get secrets out of the code and configure precisely.
Speaker 2: The best practice is crystal clear. Always store application credentials
Speaker 2: in a centralized credential store, use a managed service or
Speaker 2: a well maintained open source one.
Speaker 1: Is there a standard way for apps to talk to
Speaker 1: these different vaults?
Speaker 2: Unfortunately, No, that's a bit of a pain point. The
Speaker 2: source mentions there isn't one universal protocol. You generally have
Speaker 2: to use the specific API or client library for whichever
Speaker 2: service you choose.
Speaker 1: Okay, something to be aware of. Now, let's shift gears
Speaker 1: to something potentially more complex, securing communication between different services
Speaker 1: in our own application services.
Speaker 2: Basically, yeah, this gets intricate fast, especially as apps become
Speaker 2: more distributed. The Amazon product page example, and the source
Speaker 2: is perfect. You load one page, but behind the scenes,
Speaker 2: that single request might trigger calls to dozens of other
Speaker 2: internal micro services, one for price, one for inventory, one
Speaker 2: for reviews, one for recommendations.
Speaker 1: Well, whole cascade of internal calls exactly, and this fan
Speaker 1: out introduces new security headaches.
Speaker 2: The Source highlights to big ones, which are, first, how
Speaker 2: do you propagate the original user's identity securely through that
Speaker 2: whole chain of service calls? The inventory service might need
Speaker 2: to know who was asking, not just that the request
Speaker 2: came from the product page service.
Speaker 1: Right for auditing or maybe fine grain permissions.
Speaker 2: Exactly, But doing that consistently across service is written in
Speaker 2: potentially different languages, using different communication protocols HGTPGRPC message queues
Speaker 2: is really challenging.
Speaker 1: Is there a standard way?
Speaker 2: Not really a single simple standard. You typically have to
Speaker 2: piece together a solution using various patterns and technologies. Open
Speaker 2: any connect tokens, maybe mutual TLS, JWTs, jason web tokens.
Speaker 2: Perhaps the service mesh helps. It's complex requires understanding lots
Speaker 2: of pieces.
Speaker 1: Okay, that's user identity propagation. What's the second big problem?
Speaker 2: Service identity? How does one microservice securely identify which other
Speaker 2: service is calling it? Why does that matter for authorization
Speaker 2: between services? Maybe the product detail service can be called
Speaker 2: by almost any other service, but the update price service
Speaker 2: should only accept calls from, say, the pricing management service.
Speaker 2: You need to authenticate the calling service itself.
Speaker 1: Ah inter service authorization. Got it? How does services prove
Speaker 1: their identity to each other?
Speaker 2: Two common ways mentioned are API keys, where the calling
Speaker 2: service includes a secret token.
Speaker 1: Simple, but you have to manage those keys securely right.
Speaker 2: The other is mutual TLS or MTLs. This is stronger.
Speaker 2: Both the calling service and the called service use digital
Speaker 2: certificates to authenticate each other before any data is.
Speaker 3: Even exchanged, but for both sides of the connection essentially yes,
Speaker 3: and technologies like API gateways or service meashes can really
Speaker 3: help implement and manage either apikeys or MTLs across your services.
Speaker 2: They abstract away some of the complexity.
Speaker 1: Okay, that clarifies the service to service challenge. So we've
Speaker 1: covered a lot of ground, shared responsibility, TLS, dependencies, DevSecOps,
Speaker 1: core tech, user off secrets, management, service to service clue.
Speaker 2: It's a lot.
Speaker 1: If you had to boil it down, what are the
Speaker 1: absolute key takeaways for someone listening.
Speaker 2: I'd say there are maybe four essential security problems every
Speaker 2: application really has to solve. One secure communication channels, use
Speaker 2: TLS everywhere to user authentication, use modern SSO with protocols
Speaker 2: like open idconnect and web off, and three handle credential securely,
Speaker 2: use a centralized secret store, and four secure that service
Speaker 2: to service communication.
Speaker 1: And that last one, service to service seems like the
Speaker 1: most complex.
Speaker 2: Generally, yes, it builds on understanding many of the other pieces,
Speaker 2: but getting TLS, SSO and secrets management right provides a
Speaker 2: really strong foundation. And underpinning all of this is that
Speaker 2: devskops mindset integrating security throughout right.
Speaker 1: And the source wrapped up with a useful tip, didn't
Speaker 1: it it?
Speaker 2: Did it basically acknowledged. Look, security is huge, it's complex.
Speaker 2: You need be patient, you need to be diligent, learn
Speaker 2: the technologies step by step. If there are sample apps
Speaker 2: or exercises with the material, actually do them hands on
Speaker 2: is key, absolutely vital insecurity. You can't just read about it.
Speaker 1: Well. This has been a really insightful deep dive. We've
Speaker 1: laid out some critical building blocks for application security. Hopefully
Speaker 1: you the listener, have a clearer map.
Speaker 2: Now, but remember it's definitely an ongoing journey. The landscape
Speaker 2: is always changing, always.
Speaker 1: Which brings us to a final thought, considering how sophisticated
Speaker 1: attacks are getting and how complex our systems are becoming.
Speaker 1: What's one proactive step you listening could take, maybe even
Speaker 1: today or this week, to champion a stronger security posture
Speaker 1: in your own work something Tom all Over.
Speaker 2: Good question to end on. Keep exploring, keep learning,