Name: Secure by Default: How Tagged, Vetted Modules Transformed Our IaC Security Posture
Uploaded: 2025-08-27T17:56:01.536Z
Duration: 40 min 8 s
Description: Secure by Default: How Tagged, Vetted Modules Transformed Our IaC Security Posture

Transcript for "Secure by Default: How Tagged, Vetted Modules Transformed Our IaC Security Posture": Alright. I think we're live. Hi, everyone. I am Pravez, and I'm currently working as senior sari at Capsule. Today, we'll be talking about how we were able to transform our, infrastructure security using breaking the cycle of deploy, scan, scramble, and repeat, and and how we were able to go from spending more than 40% of our time, to less than 5% through prevention and systematic evolution. Quick intro about myself. I'm a doc dev, and a docker captain. Not should be different bullet points, but, yeah, I'm a dog dad and and, docker captain. Currently working as a senior at Capsule where I focus on security and reliability primarily. In the free time, I do write blogs and articles. When when, when I'm free, I'll share the link in the end of the slides. In medium, I write in on medium and substack. My core specializations are security and resilience engineering, but I also have a deep passion for building a system that scales. And, yes, that's my dog, Momo. He's a cavapoo. Noisy cavapoo, but, yeah, I love him. So before we, talk about what we are going to learn today, I want to kind of, like, tie up to what Ruby said in the previous talk, which kinda fits to what I'm about to talk. So she did mention about, about, 90% of the, issue that we face or security issue that we face is due to misconfiguration. 75 is due to lack of ISE compliance scan, and 88% is due to people just trying to do the right thing. Right? And this actually is true, and this is actually true. And and, like, today, we'll be talking about how you can address these things using, using, like, tagged and vetted module and go from reactive security to proactive prevention. As you mentioned, we would need to treat security as first class citizen, which will learn how to do it in using the Terraform tag module. At twelve this slide, I've added, some QR codes which you can scan to go through the slides if you want on your at your own pace, go back and forth. It's up to you. I'll I'll follow along. So let's let me paint a picture. Right? It's Friday, 4PM. You're about to leave for the day. We are we are, like, hard day at work, and and you are about to wrap up the week. And then you get an email from, legal saying soft two audit is next week, and and you need to prove that all the database has encryption address or in transit. I'm pretty sure you you might have faced something similar, not the same scenario, but could be different. But, at some point in our life, I think we all have have faced similar issues. Not similar ask, right, not issues. And if you're not in your head, trust me, you're not the only one. Did did happen more a lot than, you can imagine. This is what we call, traditional IC debt sec security debts file. Debts file because each iteration makes it even worse. Let's go through, like, a little bit of it. Right? Developer wants to move fast. They they they need to deliver, because it's a business. But in in in in the pursuit of moving fast and flexibility, they tend to be using raw resource, which introduces vulnerability. And and when you are scanning things post deployment, you find end up finding issues in production. Now what happens is when you find issues in production, you scramble to fix it. You scramble to fix it and which often requires you to make risky changes in production without being without testing it, validating it, and auditing it. And the cycle repeats. This, like, continuous vessel, like, spiral of cycle creates, like, developer frustration, leads to burnout, and and adds up to the security depth. I mean, just to add some perspective, at our peak, we were spending more than 40% of our time trying to make sure, like, any change small change in our module doesn't bring out the entire com company infrastructure down, which is not sustainable. Right? This is, like, we need to get away from it and find a better solution. And this, like, this scrambling is not, this scam scrambling is not just bad luck. It's it's due to, it's it's like, it is rooted into a deeper problem that the company has, which is costing, like, it's a symptom for a deeper problem that the company has, which is costing company more money, resource, and and sanity or developer sanity. So how we fix this? Like, is there a way to fix this? This is where our ins like, breakthrough insight come came in when we actually asked ourselves, what if security violations became almost impossible instead of inevitable? Very good. Like, like, what if right? Like, you obviously, anything can be solved with what is. But, yeah, for for this case, what if we can do it in such a way that developer can move fast, but, also, they they don't need to worry about these things. This is where our dual approach came in. First is why why not bake in security into the module directly so that when developer use it or consume it for the first time, it's already secured. Like, it's secured by default. This is where the prevention comes in. And as we all know, security is not perfect. We can't get everything right all the time. This is where systematic evolution comes in, systematic upgrade or or evolution where we use tag module, which gives us more flexibility to iterate around the module and make it better or more secure than what it was previously. As a result of this, we will we like, our, experience, we were we were able in sorry. We were able to reach from more than 40% of our time, to less than 5% to fixing the security issues. So let's let's talk a little bit about resources. Right? I mean, using resources is fine. It is not a big problem. But when you are a company and building infrastructure at scale, using like, when you use raw resource, it requires developers to reinvent the security all by themselves. Like, each if if each team is implementing resource by themselves, they are essentially reinventing security on their own. And, like, there is a configuration drift happening throughout the organization, which we are not aware of, and it it's very hard to account them. Like like like, accountability is not there. This often causes when you, like when if you are using, like, s three be like resource to build s three, then you solve the problem, fix the business requirement, but then security comes in as an afterthought. I was like, oh, I need to make sure the bucket is not doesn't have a open policy, or I need to make sure it's not public. Right? So, security even, like, causes like, using resource security causes us to think like, treat it as an afterthought, and this essentially causes inconsistent compliance posture in the organization. Like, in contrast to this, what if we use curated module mindset where where you we create a module or module where security is treated as an infrastructure, and it is baked into the module itself. When you use this, you will get a consistent configuration across your organization and and and, like, peace of mind as well. Right? Suppose if you have a a well thought, well curated model, which is properly secured, hardened, then you can be, like, pretty, like, confident that this won't break anything or or this won't open up our production to, public Internet. So, yeah, curated model mindset helps us to build in the like, configure, best practices best practices by default, and and automatically, we get compliant by default. So, like, the whole motto behind this are shifting from raw resource to curated mindset like, module mindset is we want to make sure security is impossible to get wrong when it's, like, embedded in the foundation itself. Right? So let's talk about, a quick example here. This is an example of raw s three bucket where where like, raw resource, which creates a s three bucket. Looks simple. Like, it looks very innocent. It's a bucket. It has text and but what's missing here? Key thing is it's missing encryption. It's missing logging. It it's may meter sorry. It makes missing ACL. It's it's missing, audit logs or or or object level logging. Now as a company, if you want if you are, like, looking for, like, compliance or soft soft two compliance, then, the auditor would would look for it. And and it's actually required. It's not, like, fulfilling soft requirement. You actually need this kind of thing to make a secure bucket. Right? These are the things missing, and then developer need to go back or come back and add this into the resource. But what if we use module instead? This is the same thing as previous, but instead of raw resource, now we are referencing our module, which is tagged with a version. And all the things that we talked about missing previously is already baked into the module. It has encryption logging, ACL bucket policy. Everything is configured in in those. And just three lines of code, developer now can be confident that the bucket that they create is secure, soft to compliant, or any any, compliance, like, compliant to any, what do you call, regulatory bodies. And and and they can be, like, pretty confident that this bucket is is safe and secure. That's the whole concept, from moving away from raw resource to using vetted module. So as I discussed, the we like, more using model is good for building security into the foundation. Right? Let's talk about how we, develop a mod like, do the module element. Like, it it goes through a lot of steps, but there are key like, four key phases that we use. Whenever a module is created, it is, like, vetted by multiple team. If not, it is not vetted by iInfoSec. It's not just vetted by, like, engineering, not just by SRE. It's vetted by multiple teams. We run the module through, compliance audit through tools, or or, tools like Snyk, TFsec, Checkov, and other to make sure it's compliant with other, like, regulatory requirements. And then we tag and release the module using semantic versioning. If you're aware of semantic versioning, it just basically, versioning your module based on major, minor, and and patch release. And once the module is released, we test and audit, like, validate it so that, it's it works. It is it is fulfilling its intended, purpose. And then, we, expose it to engineering or other teams to consume it. Now what goes into each and every module? Like, we talked about the process of building a module, but what each module has or what each module should have. One is it should have embedded security control so that at least bare minimum, encryption, logging, monitoring, attacks, everything is baked in. Right? It has sensible defaults to override because it should not like, modules should not should not be re rated. Like, it should be easily extensible and but, like, it should be easier to use, but hard to misuse. Like, I don't know. It like, it's it's a good phrase, but, Yeah. It should have, like, sensible override and and and, like, we should have, like, we should build a comprehensive documentation on how developer can then consume the module with with the default. We should have automated testing and validation. We can do it through pipelines, like, to run Terraform validate, or or you could do it like, Terraform is notorious on failing what and apply even if if it passes invalidation or TF plan. So you can actually do a canary build the canary, infrastructure and then, tear it down as part of the pipeline. Now all doing all of this gives developer, like, one mindset. Right? From, like, does this look secure to, like, I'm pretty sure confident this is secure. Like so it's it's all about billing confidence and security. So, like, let's talk about, like, how a day in a Terraform light module looks like. So suppose the module is already there and our SaaS or or or developer identified, security issues. How we go about fixing it? When the issues is first identified, we update the module and patch it immediately, and then tag and release it. Now based on the criticality of the, issue, we test and validate and and and depend on I will talk about how we roll things, in next coming slide. But once it's test tested and validated, they will consume the module and the cycle continues. This is where the, two approach I mentioned before where is, like, we prevented the module by creating a secure module from the beginning, but we also have a systematic evolution process where we iterate through it, to make it even better. So just, like, quick in like, information about how we manage our modules. We use tag monorepo with independent release of each module. So when you are using like, if you are using Terraform module in in, like, you don't want to maintain 100 of git repos for 100 of your telephone module. Like, it's so hard to track and maintain. So what we do is in each module, we create a version dot YAML file, which contains a version and an change log file. That change log file is is consists that change log file consists of of all the iteration that we did and the information, what was, like, changed that was changed in each, version. And then we use all of these to create a git tag for independent module. So, essentially, if you see on the right, there is a full list structure. But when we release a module for ECR, eventually, that tag will only have those four files. Main dot t f, change log dot t f wasn't at YAML. And and when you consume it, your application or source code will only only have those four files. So let's talk about how version configuration is done. It's pretty elegantly simple. It's only going to like, version.m0 has version defined. That's it. So in this version, what hap like, how it works is DevRelator makes changes to a module. We bump the version based on the change type of change. If it's a backward compatible change, we may, like, change the patch version. If it's a little bit significant change, we update the minor version. If it's, like, breaking change, we update the, major version. So once we were, like, bump the version, we execute we have a script. You can do it through GitHub action, your pipeline of your choice. Depends on the company. We just chose to because we just chose to do this shell script. It's fine. You and we execute the script which tags and release the module. So what that script does is it identifies the module or version that was changed and then compares it with the one that was released previously. And and then if it finds a drip, it, tags and releases the new module. It's simple. So as I mentioned, this is how, release works. All like script scans for all version dot YAML file for change. It compares current and previous version. When when, change is or drift is detected, we remove all the other older module which hasn't been changed in the whole, entire, like, tree structure of the repo and keep only the module which has been changed. We create a tag like this, tag. So suppose if I change, RDS provision module, then it creates a tag like region, RDS provision, and the version defined in the version file, and then we release, which is consumed by the developers. It's pretty simple. So as I mentioned, we make changes to the, what do you call it, module. Right? But it depends on how we want to roll it out. You don't want to force thing. But so we categorize the chains into risk categories. If it's a very risky, vulnerability that popped up and we have to patch everything right now now, then we, tag, release, and immediately roll out. Or or sometime, it like, you have to just circumvent the rule and just modify the existing, module so that it will be reflected across across the organization immediately. But for critical, risk, we immediately roll it out. If it's a standard, like, upgrade that we did to improve our compliance or security posture, we do a phased rollout, which is in tranches. Like so we categorize all of our resources into, like, batches and then rule it out throughout the year. So that way, developer are not, like, spending 100% of their time, rolling this, like, infrastructure change only. Right? They have a lot of other things to do. They're, like, infrastructure should be their least of the concern. And if it's a enhancement, like, oh, you added some fancy tag, which makes it easier for us, like, security scan to pick in things up. It's not important, but it's a good enhancement. Right? So for those kind of changes, we do a gradual option. You don't want you don't have to implement it right now now, but you can order it throughout the line. So so we, like, do three, like, types of risk categorization, and based on that, we roll it out. I'm sorry. So what like, we discussed about tag data for module and and how we manage this. Right? Now let's all work on how it has, like, impacted our organization. It has significantly improved our risk posture. Like, previously, we're we're fine fighting. Right? This, like, issues comes up. We will roll it out, scan, and, like, now we have moved from reactive to proactive security where we bake in security into the model itself, and we're pretty sure. Like, if you make a bucket of the private and it is consumed by everybody, you don't need to be worrying about whether the bucket is private or public, later later in the life cycle. Right? It it is already baked in. Unless somebody goes to AWS and changes the bucket to public, that's a different problem. That for that, you have you should have, like, SCIM or any kind of, like, medical security platform, which which detects these kind of, issues. It helps it helps us create a consistent compliance across all of our team. So every team uses the module that gives us confident that the structure or or the configuration of module across all the projects in our company is same. I mean, there might be some differences on the configuration values. Some might be using ideas with, like, different interest class. But, like, at its core, both all of them are using their own KMS key and not a shared KMS key. That that I can be, like, for sure, like, certain about. And it reduces our risk audit preparation time when you, like if you if you have gone through, like, compliance, like, what do you call renewal? You would need to provide all of these evidences to the the regulatory bodies. And knowing that all of the company resource are using module and and all of them use, tagged and vetted module gives us more confidence that we can just, like, provide it as a proof and and reduces our audit audit preparation time because what was last year is same as this year. It apart from, technical, change, it has built a big cultural transformation as well where security is now seen as an enabler, not a blocker. And it's more developer focused. We, it's it's a shared depository. Everybody can come and, like, contribute to the repo. No one, like our team shepherds this, but it's we are only the shepherds. We're not the owner. We're like, we have a shared responsibility model where everybody is owner of that resource. And and, model where everybody is owner of that resource. And and, basically, this helps us deliver feature faster and and better maintain better security. Like, if I had to summarize all of these in one sentence, like, security implementation or change using tag module has reduces our, experience from weeks of of trying to figure out whether what things can break to, like, minutes of prevention. So it has been a like, made a significant impact. So now after all of these, my pitch, if you are ready to implement your thirty day plan of of how we do it, here is a short guide how you can plan for your thirty day implementation at your company. At first, what we want to do is audit and prioritize top three resource. Do not try to address, like, create modules for everything from the get go because you'll fail. Right? It's it's a it's a failing challenge. So what I want you to do is audit top three resource that are used in the company. Maybe whether it can be I'm or whether it can be RDS or it can be Lambda. Right? And then build and test it test first set of vetted modules. Once those modules are created, scanned, audited, and tested, you it pilot it with one engineering team. We want to reduce the traction as well. Right? It's it's not all about, implementing CDG. We want to make sure company maintains the better CDG as well. So pilot it pilot and iterate it one team. Once it's ready, roll it out to wider, wider teams or wider engineering or throughout the company. So that's your thirty day implementation plan. One thing that I want to highlight is there are critical things that needs to be done for this implementation implementation to succeed. One is when the module is being created, it needs to be like, everybody needs to watch in for the module. I chip in I provide the insight even from executive to enterprise manager to developers from other teams. Everybody needs to be involved, or or at least consulted with. That way, what we can do is we can frame it as this risk reduction and and not a developer restriction because we are consult like, consulting and bringing in way early in the development. We want to make the module easier to use, so make sure, like, it's not too rigid. And and don't just force migration. We are talking about cultural shift or mind change in mindset. So it we we don't want to make like, force it on developers to just, like, use it. Oh, I created a dispatch written model. You have to use it. That's that will, probably not work well. So make sure it's it's it's it's, like, making it attractive and easier to implement would would bring in more consumers rather than forcing the migration. Now let's talk about common pitfalls that you want to avoid are also lesson learned. These are the pitfalls like, pitfalls that I've noticed when I work when when working with this. And and don't try to over engineer the model too much because perfection if you are aiming for perfection, the module will never be ready. You're like you'll always, like, spend almost all all of your time trying to to fix the module, but we want to move fast as well. Right? So don't want don't try to handle every edge cases. Make sure it's, like, good for the first pass. Right, and call like, you don't have to have, like, more a lot of complex configuration. Keep it simple. Don't just over engineer. Like, what we want to do is we want to start simple, iterate based on real business need, not just like some theoretical random random esoteric, security problem. So the other thing is don't make the modules too rigid because different developers or different team have different requirements. So we need to make sure there are, like, proper escape hatches. We don't want to force one size fits all approach and and have option for developers to override if it's necessary. Because some business case might need s three bucket to be public. Suppose if you are, to if you are, like, exposing some public assets to, for your website to s three, then it needs to be public. Right? Unless you are using CDN. That's a different problem. Basically, we want to make sure, like, initially, build 80% of the solution with flexibility and developer focus or developer experience in mind. The other thing is shifting this strategy is a cultural change. It's it's not, like, technical thing as just it's not just technical thing. So we don't want to force adoption too quickly. We want people to embrace it. We want people to look forward for it. Right? So we want to like, what we should not be like like, we should you you should involve developers when we are building the model because they are the primary consumers for your telephone module. The other thing is not communicating properly. You need to communicate when when some change is being done, having a good, like, feedback cycle, in place so that people can express their concern or also also suggest some more ideas. So as we all know, cultural change takes time. Like, it is not, immediate change. It may you will it might some some for for some company, it might take six months. Some for some company, it might take years. Right? So don't just, like, force it on the developers. Other than that, I'm almost at the end of this slide. So I want to leave you with with two, key things that you want to remember. Like, obviously, we talked about a lot of things. Make sure like, let's talk about, like, some strategic insight. We want to make sure also, the psychotipate, the ideas of prevention is better than remediation. Obviously, we want to remediate, with a feedback loop, but, initially, we want to make sure if something can be prevented, let's try to prevent it. Security when security is baked in or shift left strategy. Right? When you are shifting security left in the pipeline, it's it is more, like, it is more effective rather than thinking it as an afterthought and scanning it after, like, some deployment. Systematic evolution should be in place so that it can we can iterate things over rather than manual updates. And and, we need to make sure everything all of these all of the things that we're talking about today is focused with developer experience in mind and not just technical, requirement. So if you are, like, the if you are planning to implement it on next Monday morning, your first reaction should be, audit mastery resource, map your current security pinpoint that company is facing, identify your first modem candidates, and then start with one team and one use case. And then integrate from there or slowly build on top of it. So there's a saying. Right? You don't need perfect security on day one. Sorry. That there should be one, o n e one, but I I made a typo. Alright. But we do we just want to make sure the needle for security is moving consistently in the right direction. You don't have to make it perfect from the get go. That's the key insight that you want I want you to remember. Other than that, I'm open to questions. Still have ten more minutes, so let me know if you have any questions. Hey, Purvesh. That was an awesome session. There's definitely some questions. We've people have been putting them into the q and a, and there's some up votes there. So we can go through these, and I can bring them on screen, and we can answer them, based on, you know, the most up votes first. If people wanna go review what's in there, go, add some new ones or upvote. We've got yeah. Just just over ten minutes here. Alright. So let's see. Let's start with, so with this one. So as a platform engineer, I want to feed the DevOps team ISC templates that are ready to use and compliant with our policies. How can I encourage force slash force them to use these templates instead of every team reinventing the wheel? Again, this is very, like, nice question. You don't want to force these things. Like, you you want to make it attractive enough so that people want to use it. So imagine imagine somebody wants to, implement a Lambda function. Right? If you want to create a ISE, like suppose if you create a ISE template where people will get this copy paste the module and and that's give that gives them all the things that they want for the project, then that's a win win for everybody. Right? For company, you get security. For developer, it's fast. Like, rather than thinking about how to create Lambda resource, how to create all the additional resource associated with it. Like, Lambda needs eye information. Lambda might need, access, like, KMS keys. Right? All of those things. So the key thing here is encouragement rather than forcing. We want people to, like, encourage and show them, like, there's a you you're, saying. Right? When when when you make it easy or or very, appealing to consume, people will come in. So it's it's more encouragement and and make it appealing so that and and maybe one if it's the first time, you might need to hold some hands and and show them how to use it. Not just from your team, get advocates from other team who are, like, fascinated with this and and want adoption. And they will be your advocate for the company. So Yeah. Yeah. You could build some power users as advocates and get them to show the benefit to their peers. Yeah. And even better if they are costing cross like, costing, not just from your team. Yeah. Yeah. Great point. Alright. Question here from from Matt. How do you internally promote new modules with best practices, ensure they are being utilized by teams? It's very kinda similar to the last one. How also, how do you have an internal sourcing structure to enable teams to contribute to the creation of of them? So, at Capsule, we have, like, share responsibility or share ownership of repositories. And and we actually in like, encourage developer to make changes on their own. So, initially, it's not, one team that manage and maintains all of these. It's it's more like or suppose example would be if Garrett is from from engineering team and he wants he found out a issue that, the the KMS key is using sorry. I'm permission is using wildcard. Right? Now if he identified the issue, I will work with him to remediate it and and show him how he can contribute to the project and release it from start to finish. And once he's done, now he is aware of the the policies and practice practices we have because we work together, pair programming. And then, eventually, from next time onward, he knows where to do where to go and what to update and how to release the module. So, internally promoting is other like, one one thing that I want to add is sometime people slip in the resource. For that, you would need to implement a shared kind of, like, scan, which which flags use of, raw resource rather than modules. You might want to implement, like, like what do you call? Example would be gear of action. Right? If if somebody is using a resource in their pipeline so in their infrastructure where all of them are module, then it should flag and say, oh, this person like, it's not it was not it might not be intentional, but mistakenly might have been added with that because they are they are just new to the company. They don't know the model went there. So it's you might need some kind of mechanism which flags the user for our resource. But promoting, it's more like you need to be at at, like, an advocate. Like, you need to advocate with them. Great. Thank you. Alright. Here's a question from Jason, which is picking up some up votes. Can you speak about the different definitions of a module being one, a specific resource with predefined security controls? Or two, all associated resources needs to deploy a resource including a private endpoint, DNS links, etcetera? In other words, should a module deploy one resource or multiple? That's a really good question. So it depends, again, like, this they're not the answer in my question here, but it depends on the use case that company one. So example would be, suppose, if you are just building a a street bucket, it's a it it would be a hybrid approach. Because if you want to deploy a RDS, you want to make sure it has its own KMS key. Right? It has, like, suppose if you want to deploy Lambda, you will not just create a module for Lambda. You will create the more like, module for Lambda, which has its dependencies on itself as well. Like, so Lambda and I'm permission and all the extra things. Right? So one module like, it's more like one module might have multiple, multiple resource defined in it so that it, like, depends, like, on functionality. If you want to do it on on functionality, it could be all resource associated needed to deploy a resource. Right? Or or a fulfill a function. Like, some example would be I want a CDN for master bucket. Right? It meet it requires you to create CDN. It requires you to create SD bucket, all the resource, and everything for that whole functionality. You could, like, approach it that way, or you could just create individual, resource for for each module. But I found creating, module based on problems is easier and and secure rather than rather than, creating individual resource with predefined security control. But both of them would have security handling done in place. So in short, it it depends on the company requirement and how how how like, the use cases. You're on mute, Karen. Thank you. Alright. Next question here from Philip. What toolkit do you use for testing modules? So we actually have a pipeline which builds the infrastructure. As I mentioned, Terraform is notorious in failing and apply even if you build a module. So what we do is we actually build up the module and then tear it down as part of the pipeline when it's it's being released. So it it's, like, it does Terraform plan, apply, create, and we do we do have canary deployments that creates the whole infrastructure consuming our own module, and and and we validate the the checks, I mean, stem. You can do, like, checks using patch or self script or or any kind of other other tooling. K. Cool. Alright. We've got three minutes here. So maybe a couple more questions. One here from Henry. Can you also restrict the developers from using a resource in their IAC code and enforce the use of a vetted module in your organization? Yes. So we use a shared pipeline, at our company where all of the Terraform plan runs through our shared pipeline. And and SRE team maintains that pipeline. So what we can do is just do a grip of resource when the pipeline gets triggered from any team and it flags the user resource. So you can use the concept of shared pipeline, or or you could do it externally, which scans through your entire GitHub repo and and flags it. But I found share using shared pipeline, effect, like, works very effectively. Okay. Great. Question here from Rishav, who is our next presenter. Oftentimes, the dev team consuming the module wants to take make a tweak to fit their needs. However, this can break expected functionality from existing consumers of the module. How do you try to bridge this gap? That's a very good question. We recently faced the same issue because as I mentioned, each team might want things differently. So we create a vanilla module, which is vetted, tested, audited, with all the hardening. But each team can tune into, like so so for each team can tune the same model that we have into the into their, like, construct of different construct. Like, so suppose if you are a team, then basically, our module or or or, like, the vetted or vetted module is used by other team and they tweak it as their liking. But at its core, it's the main, module that, like, vetted module that we release is used by each team. They weren't so so example would be they would create their own module from, from the the vetted one if they want to make some tweak changes to their needs. Got it. Alright. We've got, one minute here. Let's get this question from Sean. How when you create a new release, how do you ensure the new tag is used by the developers? We have we maintain a registry of all the tags. It's like simple as that. We just maintain a redo file with all the registry, which is updated when pipeline is, like, module is released. And and whenever somebody needs to consume it, they just refer to the registry. It's a read me file in the repo. This is m like, mark markdown file in the repo. It's very simple. Okay. Alright. Great. Well, this is gonna end in 30. Wanna give time for people to go to the next session. And anything else, Ramesh, thank you very much. This is a a great session. There's some more questions in here which we can share and we can follow-up afterwards. Go for it. Yeah. So, yeah, if anybody wants to connect and chat more about it, here are my socials. And and specialists have has good resource on on TEFL module and how they work if you want to go and have a look and and have some references. But, yeah, let let like, connect with me and we can tech chat more about it. Thank you so much. Alright. Thanks, everybody. See you on the next session. Alright. Bye.