[0:00] Thank you for joining us today. We’re here to discuss “Bridging the Gap: Uniting Development and Security,” with a number of industry experts. We’ll start with a brief introduction, then our panelists will introduce themselves, and afterwards we’ll dive deeper into how to unite development and security, or how not to. As usual, if...
[0:00] Thank you for joining us today. We’re here to discuss “Bridging the Gap: Uniting Development and Security,” with a number of industry experts. We’ll start with a brief introduction, then our panelists will introduce themselves, and afterwards we’ll dive deeper into how to unite development and security, or how not to. As usual, if you have questions, please write them in the Q&A; we’ll devote the last 15 minutes to your questions. My name is Boaz Barzel, I’m leading product marketing and enablement here at OX Security, and I’m passionate about discussing security topics, especially around the AppSec world, with audiences around the world. Let’s do a quick round of introductions. David, let’s start with you.
[2:08] Thank you, Boaz. My name is David Coral, I work for Repsol, a multi-energy company headquartered in Spain. My background has been in cyber security for more than 15 years, and now I’m leading security-by-design and security architecture practice globally for Repsol, and of course application security. This gap we need to bridge between developers and security is more and more challenging but more and more needed, because the way applications are evolving, the time to market, and the speed teams need mean those two disciplines have to work very tightly together.
[3:06] Fantastic, thank you David. Ria, over to you.
[3:13] Thank you, Boaz. Hi everyone, my name is Ria, I’m based out of Toronto, Canada, representing SAP today. I’m a product security architect associate at SAP. SAP creates software for managing business processes; my role is to ensure product security by researching threats and developing baseline requirements teams can follow, primarily leading the development of baseline security practices for AI, which is new now. The way I see my role is to understand these threats and translate the requirements into what that feature looks like in the development world, how coders or data scientists apply these features in their product, and what processes in the secure software development life cycle they can implement to safeguard the data, the model, and the environment.
[4:28] Thank you very much, Ria. Miglen, over to you.
[4:35] Hello everyone, thanks for having me. I’m Miglen, leading information security at Payhawk; we’re an expense management and corporate card company, Bulgaria’s first unicorn startup. I’m also the founder of a cyber security foundation, working toward fostering a healthy infosec community in our country. What I’d like to focus on is the cultural aspects of the gap between security and development. I come with more than a decade of experience in companies like Amazon and HP, working closely with development teams, and a development background, so I’ll be very interested to hear the other panelists’ views.
[5:38] Very good. Gabriel, over to you.
[5:46] I’m Gabriel Enright, a principal architect at the Vodafone Group. We have 623 million customers, so we’re a very big target; there are over 5,000 applications, so a lot of vulnerability. My role is on a platform team; we deliver secure platforms across our group, which takes most of the security aspects away from development and embeds it in the DNA of delivering software. That approach has been quite successful, so developers can get on with developing code and always deliver into a secure environment; we abstract away the hardcore security so not every developer has to do it every time.
[6:53] Fantastic, thank you Gabriel. Last but not least, Liad, over to you.
[7:05] Thanks, Boaz. Hi everyone, happy to be here. I’m leading engineering and security at Rakuten Viber. For those not familiar, we’re a super app with a huge user base, hundreds of millions of users, serving as a communication hub, everything from calls, messaging, and groups, end-to-end encrypted by default. We’ve created an SMB platform we’re rolling out, and a digital wallet expanding rapidly in Europe. Altogether, it means we fit perfectly to almost every textbook cyber-attack motivation a bad actor has, from fintech to monetization to even political aspects, so that’s part of our day-to-day: how do we develop so many things and continue to be very secure.
[8:40] Thank you all for the introductions. Before we dive deeper, a few words on what we’re discussing. The pace at which everything happens, from development to business, means security innovation is becoming more and more critical. We’re trying to push boundaries and anticipate new threats, because the adversaries are innovating too, trying to find the places not covered where they can inject code and achieve their objective. So the need for a strong security posture is high, and we see a gap in the relationship between development and security. Security tries to keep the organization and applications secure and not vulnerable, but sometimes hits a place where developers aren’t paying attention or aren’t putting security at top of mind. Both security and development are pillars of strong, secure innovation. Some pain points: development teams pressured by deadlines view security protocols as obstacles; security teams striving to protect the organization feel like they’re on the sidelines, seen as nice-to-have rather than part of the pipeline. This friction impacts efficiency and morale, people get frustrated, and the consequence for businesses is that instead of releasing secure software on time, they release insecure code and fix it after the fact, which is much more difficult and costly than fixing it during development. So today we’ll tackle these challenges one by one, explore how integrating security into the development life cycle enhances product quality and reduces release times, and pave the way to bridge that gap. Let’s start with the first question. Ria, what role do AI and machine learning play in security within the development life cycle, and how is the market reacting?
[13:32] We’ve all experienced the impact of AI across multiple industries. In cyber security today, a lot of tools are leveraging AI and machine learning, helping the shift-left movement, incorporating security in the design phase. There are tools that help with scanning and remove false positives, a huge overhead for development teams; AI and machine learning models play a huge role in removing that overhead. There are LLM-based malware scanning tools that scan through code, which takes the guesswork out of development. So understanding what we need to do in terms of scanning, malware scanning, and identity and access management, and incorporating AI-leveraged automation tools that cover these scenarios, helps that end-to-end process where we identify, fix, and report on compliance. It provides a huge opportunity in the current development life cycle.
[15:41] That’s good. When we think about AI and machine learning, we also think about the development side, the security side, and the attacker side. What are your concerns with AI or machine learning?
[16:15] There’s a need to include a human in the loop. When using these AI models, you’ve experienced ChatGPT drifting, Microsoft’s Copilot drifting; can we fully rely on this? A lot of scanning tools say they’ll eliminate 90% of false positives, but we really need that human-in-the-loop interaction to identify when the model is misbehaving or not adapting to changes.
[17:07] If I can add: some of the challenges in security here are that developers are going to leverage AI to produce code quicker and in a more structured way with higher time to market, but there’s a challenge in the security of the code those tools produce. The market has to address that, the AI tools like GitHub Copilot, and SAP has its own tools to develop with AI assistance, have to take care of the potential introduction of vulnerabilities through AI-generated code.
[18:19] Very good. David, how do you see the integration of security and development reshaping market trends in cyber security?
[18:34] The application security market has been there for many years. I’ve lived the process of implementing a lot of tooling for SAST, DAST, SCA, all the different domains, but to be honest it continues with some of the same challenges we had five or ten years ago: a lot of false positives, difficulty engaging development teams, and leveraging the findings. The consequences are the same: we lack resources to remediate vulnerabilities timely, and many times remediation comes late in the project life cycle, increasing cost. To close the gap and improve the general posture of security in the development life cycle, the market has to bring focus to the results, to be efficient and scale to the amount of development happening, and give customers a complete end-to-end view of the DevOps process, from access to repositories, to development, to deployment of the infrastructure, and prioritize the critical exposures to give developers relevant, precise information. The market is recognizing that, and trends like the ASPM market prove that somewhat.
[21:16] Gabriel, anything to add?
[21:21] Since we’ve brought up AI, a challenge in the past for us is the Shadow IT effect, where developers have a more liberal position on what tools they can use, while on the corporate side we lock that down. Shadow IT can introduce a lot of vulnerabilities. But there’s a new kid on the block now, Shadow AI, where developers are keen to use AI tooling to develop code, and the corporation is just catching up and hasn’t published those tools, so they’re generating code on tools that aren’t in our mix yet, and we don’t know what impact that’ll have: who wrote the code, where it was generated from, what’s in it. We have a human in the loop, but humans make errors too. So there’s a big vector where developers could use AI, if it’s not within the organizational tool set, to introduce vulnerabilities, and we’re seeing that a lot now, which poses a big security risk.
[23:09] Interesting. We talk about human errors, and I was thinking, if a human makes an error and uses AI, doesn’t it make the error bigger, because the AI expands what the developer wants? If we see an exponential amount of vulnerabilities discovered, wouldn’t that cause a larger problem?
[23:51] If you train the model with an error, now everyone has the error. It’s a new world, very different from downloading libraries; if we’re training the model on insecure things and errors, everyone else picks those up too, and it’s very hard to get them out of a model. That’s our focus at the moment.
[24:22] Liad, where do you see market leaders like yourself investing in balancing security and development?
[24:43] There’s a huge investment. As the panel described, we have Shadow IT, AI, and especially as a super app, a ton of regulations, every year brings new ones, compliance, basically every letter in the alphabet: PCI, GDPR, CCPA, DSA is the new kid on the block, SOC 2 Type 2, everything. There are two verticals I like to talk about. One is technological: we have to find better tools and deliver fast in a fast-paced world; in two-week sprints, when you add up development, QA, and a ton of security aspects and regulations, two weeks is barely enough, so we have to be creative. The other vertical we invest a lot in is culture: fostering a security-conscious culture among developers, bridging that gap, aligning everyone so they understand what it means to release a vulnerability. It’s getting faster and faster in the cyber realm; every week there’s a new threat relevant for different teams, so we invest there and find that sweet spot between technology and process. We have strict objectives on velocity, and even when adding layers of security in your CI, production, and corporate environments, you have to make it as seamless as possible so developers and the business aren’t annoyed.
[28:30] Let me connect that to Miglen’s note about culture. Miglen, how can we improve the relationship of developers with security?
[28:59] Generally, I don’t think developers really enjoy security, because the engineering organization’s purpose is to be efficient and solve problems fast, and security might be seen as something that slows down releases if not done correctly. Luckily, nowadays we have a lot of tooling and practices to ensure security is not a blocker but an enabler that speeds up releases and builds trust with customers and partners. I like what Liad said about the balance between functionality, usability, and security. Security leaders need to step up and reach out to development organizations to understand their process and way of working, to tap into their processes and tooling. There should be a deep understanding of each organization’s goals, processes, and pain points; if we experiment with the right tooling, not just bringing in something Enterprise we heard works somewhere, we can build a very efficient SDLC process where security is integral at each step. On the AI side, almost every second offering mentions AI now. From both sides there are risks: engineers can now solve problems efficiently at scale with Copilot, which is amazing, but they could create more problems at scale, especially business-logic compromise that other tools can’t detect. And I’ve seen AI models hallucinate when generating a policy, an IAM or WAF policy for some tooling, and if we don’t thoroughly check and verify, we might end up not securing something enough.
[32:06] We’re trying to prevent risk at scale, not create more problems at scale. Gabriel, how do organizations manage the interface and challenges between development and frameworks like secure by design?
[32:50] The developers won’t like me for this one: we try to abstract all the security away from the developer. They use pipelines with scanning tools; specific environments scan code; when we detect vulnerabilities, they can’t migrate that code into a higher environment until they resolve the issue. We have tooling in the environments, like edge networks doing the WAF-type work and dealing with threats coming in. That’s the platform approach. The problem with security is that people have to manage the security; we try to take the people-management of security out of the equation and secure a pattern. So when a developer wants to build something and put code into production, they use a secure pattern; if there’s no pattern, we create one or a capability, and everyone gets the benefit. It’s not leaving the developer to their own devices with security, it’s giving them a framework or ecosystem where they can’t promote insecure things into our environments. With thousands of applications, it doesn’t scale to have people doing security in those volumes. We’re not locking it down or taking away creativity, but we’re taking away the threat of many developers doing things in different ways and introducing vulnerabilities we clean up later. You order our secure services, secure images, and secure pipelines, and use those because we baked the security in.
[35:07] We follow a pretty similar approach; building platforms developers can rely on and anchor on is really key. We’ve also tried to put some responsibility in the different scrum development teams, because that’s the last mile: they develop the application and use the mechanisms the platforms put in place, but at the end they’re developing, and we rely on them to solve some vulnerabilities. But strong platform foundations are a huge jump, so we have a team in charge of providing development capabilities, working tightly with security to set requirements and tooling and embed it into pipelines and images.
[36:39] Just to round that out, the secure-by-design aspect: with proven patterns, projects get through quicker because the security teams can just review, yes, you’re using that pattern, scanning your code, using those pipelines. If it’s a blank canvas, you usually get a spreadsheet with about 600 vulnerabilities and have to comment how you’re addressing each. The idea is to not do that, to use approved secure patterns, which makes your journey with secure-by-design, who let you gate to production, a lot easier. If you come with something that has a lot of potential vulnerability, you’ll have a much bigger engagement with security; if you use approved tooling and patterns already security-reviewed, the journey is quicker and less cumbersome.
[38:12] Ria, you wanted to comment.
[38:18] Overall it seems there needs to be tighter collaboration between security and development, where security can point out the pitfalls and threats development may not see. When features are developed at the app or platform level, it still takes two sides; the application team still needs to incorporate and configure these features. One methodology we use comes in handy: threat modeling, where we see what threats can impact the specific use case, which should be incorporated in the design phase. And we always have to understand there’s a trade-off; can we completely protect something? There’s a risk threshold we identify: this feature is too risky, or we can’t move forward without certain features based on the type of data.
[39:49] Taking that deeper, we talked about technology and the platform approach. David, let’s talk about communication, because developers and security are people. What are the communication barriers between the development team that wants to stay on schedule and the security team that doesn’t want to release vulnerabilities?
[40:27] The original barrier comes from the fact that developers’ drivers are mainly functionality, efficiency, cost, speed, and time to market. Cyber security is a needed foundation for the value of the application and product, because without security you can’t have a sustainable product, but it doesn’t add directly to the developer’s equation of cost, efficiency, and speed. Also, past approaches put another responsibility, the security hat, on top of the developer, which is difficult to communicate if you’re not giving something in return. To improve communication: first, they have to be aware of the context; we have to spend time explaining the scary cyber-security context, the importance of customer trust and of not having an impact from an incident, because attackers are evolving and just need to exploit one vulnerability to cause huge damage. So explain the context and make them aware of the company’s security strategy and their importance in fulfilling it. But that can’t be alone; we need to be practical, give them the patterns and mechanisms prepared, be precise, give accurate requirements, translate requirements into what’s relevant and actionable for them, and prioritize the critical applications. Summing up: be clear in communication, integrate automated controls into their tooling with accurate findings, and be there continuously, this is a journey, not a one-shot; we can’t just name a security responsible in the DevOps team and think it’s done. We have to support, adapt requirements and tooling, and be aware of that.
[45:01] It’s really security’s responsibility, security education, communication, and awareness. It’s the security team’s responsibility to maintain the level of awareness and communication so developers have a continual touch point with security, the evolving threat landscape, and incoming policies. When it comes to bridging the gap, security has a big role in that education, communication, and awareness piece that developers consume.
[45:54] If I may add to what David and Gabriel shared: maybe because I started as an engineer and love to code, in a lot of conversations it’s seen as us versus them, the developers want functionality and to release as fast as possible. But my approach is decentralized: how do I empower the developers as much as possible, encourage ownership of code and responsibility, that once you ship something you have full ownership. It’s much more than communication; in some cases you call it champions, you call it platform. It’s really a matter of budget: in huge companies like SAP or Vodafone there are platform engineering teams building a huge shield around developers, but you need to see what’s right for the company. It’s the state of mind of how security empowers developers so they don’t need us as much; we’ll always have job security, there are always new threats, but if you want to scale up with more features and verticals, I want to make sure I don’t need to hire 20 more security managers.
[48:14] Interesting, the different approaches, from fostering culture and training and educating developers to getting them to own everything they do. Miglen, what are the areas around application security and the development organization they need to invest in, and where do we need to invest most, and why?
[49:03] That’s challenging, and it’s based on the stage a company is at in their cyber-security maturity. If they’re just starting, they need to focus more on static analysis and tools that identify low-hanging fruit, then slowly and gradually build the culture, but carefully, to not cause a lot of pressure on development teams. Every little experiment with security tooling or practices needs to be done, as Liad mentioned, with a focus group or people interested in security in the organization, security champions or AppSec team, ideally coming from engineering, so it spreads and the user experience from a development standpoint is easy to follow and integrate.
[50:44] Just to add: when you bring a feature live, it’s not just the application; there are integrations and changes in maybe 10, 15, 20 systems to make a product work. That end-to-end security often gets overlooked. If you decouple things onto different clouds, you introduce more vulnerability. That end-to-end piece is many development teams coming together, so you need to be very coordinated; an architect should develop a plot with a minimal attack surface, and everyone works in concert. When we send things live, there might be changes across the whole environment, new networks, new clouds, so it’s the overarching end-to-end security view, the posture, and multiple development teams work into that posture just for a single product, far more complex than looking at the development of one application.
[52:32] You’re correct, and someone asked about legacy systems; we’re not living in a linear, homogeneous world. It’s complex: Shadow IT, lots of clouds, integrations with third-party providers, API systems, dependencies in images or packages we don’t know where they come from. So the approach should be to simplify as much as possible and prioritize based on high impact and low difficulty in the beginning, then focus on bigger problems that need more investment and expertise, like dynamic and runtime scanning, and security reviews, which are challenging for developers to start with because they don’t see them as efficient use of time. This boils down to complacency in the engineering world toward security, because most people haven’t experienced a breach. Those of us in infosec have seen or prevented a lot; literally this week I prevented something that could have had an impact, and I use that to drive prioritization. Security is everybody’s responsibility, not only ours, so we need to reduce those silos, because a developer could introduce something on staging, pre-production, or even their laptop that could be compromised and pivoted elsewhere.
[55:31] One final point: if we look at the CIA triad, confidentiality (encryption) is a known quantity with patterns, integrity (locking down and auditing databases) we know how to do, but the big one is availability, that your application is always available, which a lot of people miss. It’s not necessarily the developers’ remit to scale to a mass-market load. Availability is hard: I can make you unavailable in a thousand ways, volume-based attacks, knocking out a connection, overwhelming a server, and that’s job done for a hacker. With many development teams, your application might scale, but you only need one piece of the chain to not scale or be vulnerable and unavailable, and the whole system breaks down. So determining the impacts on your code under mass-market traffic, and the ways people can make it unavailable, takes a higher level of architecture working hand in hand with security.
[58:07] That leads to complexity, because there’s a third side to the coin: the business and what it wants to achieve. The business moves at its own pace, tells developers what it needs, and security’s responsibility is to secure the application but they’re not the ones fixing the vulnerabilities. Focusing on security: to find the biggest thing to take to development to fix, I need to understand where my business is going, how to scale, and choose a platform approach or others. And I’ll throw compliance into it. Ria, where do you see compliance and the challenges it brings, where the business has to be compliant to work with others, developers don’t care about compliance, and security is in the middle making sure everything is compliant?
[1:00:00] In the struggle between business and security, development is a bit stuck, always under pressure to develop new features, because if you don’t adapt to new technology you become irrelevant. Then we add security requirements, especially things like PCI compliance or FedRAMP, which adds a lot of roadblocks; in smaller teams, they have to take focus out of development and onto compliance and are really overwhelmed, especially teams without security champions, so it’s super challenging.
[1:01:31] [Connection issue; Ria reconnects.]
[1:01:58] In the meantime, the audience is probably expecting: we’ve talked about the market, technologies, and challenges, so what do I do with it? Let’s do a short round on best practices around culture and tooling. Liad, let’s start with you.
[1:02:48] You can start simple, with early involvement, from the ideation part, to see how much time you have to invest; in our fintech vertical we may need to invest a lot more. While developing the feature there’s education and awareness, and we need a good feedback loop between all sides to improve and learn from past mistakes. At Viber we also have a gate process, gate one, gate two, so the big things aren’t missed, with full transparency on all major features we release. Personally I’m a fan of shared objectives: from one side improve velocity, from the other improve the security posture; if you put everything as a shared objective, it’s no longer an argument, everyone’s on board. I see security like a suit of armor, so you need a good tailor and to tailor the suit to the company’s DNA; if you take culture from a different company and brute-force it where it doesn’t fit, you’ll fail. You really need to understand the people, because in the end we all depend on people; we can add layers of protection and technology, but we have to tailor the security suit to the company.
[1:05:10] Expanding on that cultural element, more than dev and security, it’s the culture of the business and how we work as a company, and finding the best fit for the organization. Ria, let’s return to you to complete on compliance and your best practice.
[1:05:52] Compliance can be a roadblock. From our perspective, what Gabriel, David, and Miglen put together is to break down compliance requirements; as security experts it’s important to simplify these into consumable, actionable requirements, what they need to do in the code. To do that, it’s not just development learning about security, but security teams updating with new development strategies: what release methodologies folks use, how their release cycle works, new technologies like AI and the new attack surfaces. Security needs to continuously update, break those requirements down, and have a feedback loop: if teams can’t comply with certain measures, can we modify the requirements for our specific use case? Really tailor it, and give them examples of what that security feature looks like, getting into it with the development team.
[1:07:34] I love getting security to learn about development. We constantly focus on security, but we also need to understand developers and how they work and what drives them. Miglen, your best practice for bridging the gap, related to compliance?
[1:08:14] We operate in a heavily compliant and regulated environment as a fintech, ISO, PCI, banking and financial regulations. One thing that really helps is making sure the basics are there: identity management, in terms of systems, machines, and people, having full control and visibility, the bare minimum, and everything built on top of that. Regulations don’t yet dive deep into secure software development; they scratch the surface with general guidance, so you should do way more, because non-compliance might mean loss of license or business, but a breach would mean out of business. Compliance creates a lot of friction with development teams who don’t understand it; if not done properly, I’ve seen security and compliance teams reaching out at the last minute without preparation asking for evidence, which doesn’t work efficiently and causes a larger gap. If there’s an early setup of expectations from both sides, what needs to be done in what phases and why, and you think about doing more than the minimum, at scale, with instruments and tooling that integrate with auditing systems, you can produce it efficiently and focus on integrating secure development practices into your workflows.
[1:11:11] Compliance by itself is really not enough; you need to take it further, it’s the bare minimum. Gabriel, your thoughts on compliance.
[1:11:37] Compliance is a cost; it doesn’t generate revenue and doesn’t save you money, except by avoiding a fine. Businesses tend to get to a position where it’s the least cost. You need to ensure that when you do a project and bring a new feature to market, part of that project has money for the compliance pieces, because you don’t want to release it and attract compliance problems. Business tends to shy away from costs that aren’t revenue-generating, so it’s a real struggle to get enough investment for technical compliance (that our environments comply with PCI and so on) when the business has a real drive to get to market quickly. All we can do as technologists is surface the issue and the risk: if you risk being non-compliant, that would attract a fine of X, you can sign it off, but if you’re deemed non-compliant you’ve put the whole business at risk. A mature business factors compliance cost into investment plans; immature ones cut corners and take risks. Getting that balance and maturity right is a science in itself.
[1:14:17] Do you feel it’s easier to explain compliance to development than security vulnerabilities?
[1:14:25] Developers need requirements; you need someone to distill what the compliance means into technical requirements they follow, as acceptance criteria on user stories, for example. Developers need a steer on what this means technically and how to implement it, rather than throwing them the regulation to interpret, because that’s how you get in real trouble. We use a lot of offshore teams from different cultures who don’t have the UK regulatory background; we as architects do, so we distill it into acceptance criteria (in agile and SAFe) or requirements (in waterfall), and unless you satisfy those, the feature doesn’t go live.
[1:15:47] David, your advice on bridging the gap from a security perspective.
[1:15:53] I’m aligned with my colleagues. To add: a good best practice is to share a common framework that supports the different phases of the DevSecOps program, good governance, a threat-modeling practice, security requirements shared between security, developers, and engineering, and a good set of automated tooling everyone adheres to, which for 80% of cases covers most developments. Second, have a very good understanding of the DevOps spectrum in your company and a good inventory of applications, which means understanding the business, their priorities, and where investment will go, which applications are prioritized. Third, be prepared for not having a one-size-fits-all approach; you can address a high percentage of teams with a platform or framework approach, but you’ll have 30 to 40% of legacy systems, a mix of ecosystems, that you need to assess differently, less automated and precise, devoting resources. It’s also good practice to reskill people, not only in security but in development and application teams, who from a more functional level could play a role evangelizing the security message.
[1:18:39] Very good points. Let me take the last 10 minutes for audience questions. The question is: have you encountered a project where the gap between security and development seemed too wide, and if so, how did you bridge it?
[1:19:33] I can tell, not a single project but many times, I’ve felt that some teams are really aware and engaged with security, where you have a level of trust and work mechanically and fast, but others where I’ve faced a lot of negotiation between what security says and what the DevOps team says. That’s the percentage I mentioned; even with automation and a framework, you’ll have situations where the way to approach it is spending time with developers, explaining why something you defend is critical and why it can create a problem, and prioritizing the fix. Common and shared goals are good advice when you find things working that way.
[1:21:21] From our side, we see a lot of projects, usually green-field projects where you see that huge divide to start with; making changes to existing things is easier. It’s about your approach. If you work on the basis that I’m going to use secure patterns and everyone uses them, around connectivity, encryption, and such, you assemble the project from patterns that already have security baked in, and then you have a gap, a delta, the new things, and that’s where the really intense security scrutiny needs to go. So I overlay the patterns onto my design, here are the gaps; this one’s going to use AI, we’ve never secured AI, so let’s put the security effort into getting a pattern for AI the organization can use, put that back into the library, and the next project can lift the AI pattern. You have to work smart with security; at any one time we might have two to three thousand projects across the group, so if we started everything from scratch we couldn’t scale. That’s why we drive a pattern approach: secure the pattern, projects use the pattern, identify the gap, build a new pattern, roll it back in, and the next program takes it on. That’s how we keep that big gap between development and security in check, because now 80% of the security work is around using their patterns, and the security person just identifies the new things that need a new pattern.
[1:24:48] Fantastic. We have about five minutes left; let me open the conversation. If there’s anything you’d like to add, you have a minute.
[1:25:23] Maybe to add to the last conversation: a risk assessment to see the impact and the risk happening in the gap. When security and development are too far off, there are typically two issues: they don’t know the processes they’re not familiar with, so maybe security hasn’t clarified everything and can improve; and the business side, like shortage of resources, skill set, or budget for tools. Identifying that is important, so it can be raised to the board: at a large scale we have issues with a particular skill set, maybe open source or scanning tools, and how can we centralize some solutions to support the teams.
[1:27:08] We only have three minutes left, but one area we haven’t touched is identity and access management, which is baked into everything: every time someone touches a tool, we need to audit what they’ve done and they need to be authorized to use it. That’s probably a whole webinar in itself.
[1:27:36] I’d give it a few more webinars; it’s a huge, very interesting topic, evolving very quickly. It’s the start of the kill chain; it starts with identity and access issues. What I want to do first is thank all our panelists; it was fascinating, with wonderful, illuminating discussions that contributed a lot. I’d like to thank David Coral, Ria, Miglen, Gabriel Enright, and Liad for joining, and our audience for participating. I hope we can continue this level of discussion, and really reduce, bridge, or eliminate the gap altogether between development and security, and help our businesses grow and be successful. Thank you very much for joining, and I’ll see you next time.
[1:29:11] Thank you very much for the invitation and the opportunity. Thank you, bye.
