Transcript
Episode Five: CISO on the Seesaw
Alice and her team at HelixCo have been pushing hard to get a major new feature out—an 80% rewrite of the front end, rebuilding the old server-side pages into modern web components communicating over GraphQL. It is a lot of code to push out, but if her team pulls it off, it will be a major feat: from janky to swanky.
Alice is the lead developer, and after several days spent resolving merge conflicts, she’s now a little crunchy. One of the juniors on the team had gotten a little overzealous on the feature branch, some hotfix had been made on prod, and she herself probably shouldn’t have redone the bits that talked to the backend at the same time as the backend crew was revving their interfaces. It all took longer than it should have, but they made it into orbit. Automated tests were all green, and even the dreaded executive demo didn’t result in last-minute demands to tweak major functionality.
All they had to do now was land that reusable launch system and push it live. She could see the light at the end of the tunnel. Shipping the code was going to feel so good—to finally have it live and in the hands of actual end users. Just had to get through this change review board meeting.
This was something new and, as far as she could tell, some kind of formality. Something about FedCramp compliance or some other box-checking. She was daydreaming about adding another Easter egg to the project—a personal signature that would only be viewed when a dev opened up the JavaScript console on her site. Maybe a way to recruit talented new front-end personnel… When she heard those terrible words:
“Um, Alice? I think you’re on mute. Uh, can you let us know your thoughts on that?”
Uh-oh. Busted. There were like 20 people at the meeting. Looking at the virtual meeting attendee list, nobody else was named Alice. Oh no. Worst-case scenario. Play it cool—probably just a formality.
“Uh, sorry. I think my network dropped for a second. Can you repeat the question?”
The voice was familiar but someone she didn’t talk to that often. Her eyes scanned the attendee list, looking for who lit up. Ugh. They had a “C” in front of their title.
“Yeah, this is Bob. I was just saying, I don’t see a record of your new project being scanned in our ASPM.”
Uh-oh. A quick Google of ASPM revealed that Bob was talking about an application security posture management system, like a big place to record all the security scans of different types. Alice looked back mentally—had she missed an email on this?
“So, we sort of have a problem here. Um, apparently you didn’t put one of the Total Protection scripts into your CI/CD pipeline to, you know, scan your code during development.”
Alice desperately tried to think of a convincing and original explanation—and failed.
“Oh, yeah. Sorry. We forgot. We’ve been cranking to hit the deadline.”
The excuse fell flat.
“You see, we’re now doing scans on all the code before it goes out, right? You did get the email?”
“Oh yeah, sure thing. But we’re shipping tomorrow, so we can do it right after the release. It’s no problem.”
There was an awkward silence.
“Yeah… Well, if you could just go ahead and follow the process from now on, that would be great. My team will take it from here, and maybe you guys can ship during the next change window? Okay everybody, we’re up on time, so thank you. Good meeting. Oh, Alice, a member of the AppSec team will be in touch with you. We’re a bit backlogged, but it should take no longer than, probably, I don’t know, two weeks?”
The meeting ended, and the white glow of the shared project board was replaced with the dark mode UI of her conference software. Alice caught a view of herself in the shiny laptop screen—a face tired, with eyes as red as the lines and the diffs that she’d been reviewing over the past few days. No. No. This would not stop her. She was going to ship. If they wanted a scan, then they’d get one.
She started looking for that email about the new security process. Oh, okay. That was a lot of emails. In her defense, she had been busy. She logged into the DAST tool. She had never used it before, but it was pretty easy to set up: point it at the staging site and give it the test credentials they used in automation. Now to wait. It was probably going to take ages.
She looked back at the progress bar and inhaled sharply and blinked rapidly. Done. Done already? Had she been napping? Whatever—it was time to look at the results.
Oh no. That was not good. The tool was not happy at all. It showed a long list of high-severity cross-site scripting alerts. Not in her new code—well, okay, except a couple of, uh, you know, easily fixed ones—but in the stuff that they had refactored and shuffled around, exposing cracks that had been previously paved over by another layer of code. But there were so many! There’s no way that this could be correct.
Alice clicked on the proof URL at the bottom of the tool, expecting some security BS write-up lecturing her. But it took her to the app, where her cookie was still fresh and allowed her to log in. And it popped up an alert box. Uh-oh. She went back and clicked another one. Another pop-up.
That simple gray box spoke directly to her core as a developer: arbitrary JavaScript was being executed in her shiny new app.
Alice was crestfallen. She wasn’t going to ship after all. She wanted to scream, to blame someone, to curse the old code that her beautiful masterpiece had been built upon. Her other monitor was still mercilessly showing that email from Bob: “By shifting left, integrating into your CI/CD pipeline, and scanning as we build, we can find and fix issues before they become a crisis at the end of the release process.” Ugh.
Soon, her Taut IM client was lighting up with automated deployment messages from all of the other teams. The trains were pulling away from the station, and she was left standing in the dark and cold on the platform. If only they had scanned earlier. If only…
Dan Murphy: Hello, and welcome to another episode of AppSec Serialized. Today, we have a very special guest joining us. We have Matt Sciberras, who is a real-life, actual CISO. Matt is our CISO here at Invicti Security. Matt, can you introduce yourself to everyone?
Matthew Sciberras: Yes, sure. Thank you, Dan. Thank you for the introduction. Indeed, I am Matthew, and I’m the CISO here at Invicti Security. I live on a tiny island called Malta. I’ve been here for 43 years—yep, I’m 43 years old. For me, security has always been an inspiration. It’s something that helps me wake up in the morning, knowing that I’m doing something good and giving something back.
Dan: Excellent. And for the record, Matt, as a CISO, is a joy to work with. He’s a good guy. Matt, for our listeners who might be more on the practitioner side of things, what exactly would you say you do here? What’s your day-to-day life like as a CISO? Can you describe a day in your role?
Matt: Sure. Of course, no day is the same. However, in reality, what we do as CISOs is align security with business objectives. How we do that is quite important because we want to minimize risks as much as possible while also enabling the company to take calculated risks.
I try to focus on a north star. I essentially divide my time into different percentages on a day-to-day basis. For example, 20–30% of my time is spent on strategic planning. The idea is to look at long-term security initiatives, align security with business goals, and develop security roadmaps. That’s the foundation of everything. When it comes to information security, strategic planning is extremely important.
Half of my time—around 50%—is dedicated to day-to-day operational activities such as vulnerability assessments, compliance, incident management, and similar tasks.
Dan: Yeah, keeping everybody safe.
Exactly—that’s the idea. Of course, you also end up dealing with unplanned instances during the day, so you need to be dynamic and able to react quickly.
Ideally, meetings would take up about 20% of my time, but we all know that’s not realistic. Twenty percent isn’t ever achievable. I try as much as possible to make time for everything else. In fact, the last thing I focus on is research and development. I want to understand the evolving cyber threats and emerging trends around us. I also want to stay up-to-date with new security technologies. This is all very important because we need tools, and we need to understand the environment around us.
Dan: Excellent. That strategic element is something I benefit from personally. Your team occasionally puts out intelligence reports about what’s happening, like the buzz on the dark web. Balancing reactivity and long-term strategy is interesting, right?
Matt: It’s extremely important, Dan. At the end of the day, we’re an online company. We’re also an AppSec company, and we want to be world-class. So, we strive to maintain a maturity program to ensure we have the right security posture.
Frank Catucci: Thanks, Matt. Since we’re an AppSec company, and this is an AppSec podcast, I’m going to shift gears a bit. Here’s a question I think a lot of listeners, especially those with CISO responsibilities, would want to know: application security is clearly one of your key focus areas. From your perspective as a CISO, how would you describe your ideal AppSec program?
Matt: Sure, that’s really obviously one of the key fundamentals in having a good security posture. In fact, we focus on three major pillars: people, process, and technology.
I always start with a framework—a go-to place. It doesn’t make sense to grab bits and pieces from different frameworks and try to create your own. I love following NIST 800-218. It’s a great set of standards for building something significant in today’s environment, especially in secure coding.
You need to have strong security policies, coding standards, and guidelines because developers need a certain level of understanding about the company’s risk appetite. But having this written down isn’t enough. You need regular reviews to ensure the controls in your policies and frameworks are actually being followed.
Training is another key area. Developers, QA teams, and other stakeholders need to be trained in secure coding practices. Everyone should understand, for example, the OWASP Top 10. These are all important things a developer needs to know. To teach these effectively and create awareness, I personally think gamification is a great approach. Developers care about security, but their primary focus is coding. Through gamification, you make learning less painful and more engaging. Developers can move to the next level while learning security concepts.
Dan: Right. I’ve said this before—developers don’t resist security; it’s just that security becomes another responsibility on top of everything else they’re doing. Making it fun through gamification is a great way to handle that.
Matt: Definitely.
Frank: I have a follow-up on that. If we talk about this from the developer’s perspective, historically developers have had core responsibilities—getting features, code, and components out the door in a given timeframe. Has there been a shift? What’s your approach to incentivizing security from a developer standpoint? If we’re saying responsibilities are shifting toward writing functional code that works on time, how do you build that additional layer of security into their perspective? How do you make them see that it matters for their performance and ensure the code they’re writing is secure?
Matt: Yes, sure. There are different areas to focus on. For starters, we’ve recently introduced a Security Champions program. I think having Security Champions is extremely important within an organization because, at the end of the day, you want to bridge the gap between development and security.
Apart from that, of course, there are a lot of tools you need to take care of, starting with vulnerability management. Within this space, we’re talking about tooling, such as static application analysis, which is a very important tool. It’s the go-to tool because, as much as possible, you want to find vulnerabilities in code early in development.
Then we have our own area, which is dynamic application security testing (DAST) tooling. For me, that’s not just because I work at Invicti, but it’s my baby. At the end of the day, with DAST, we can detect vulnerabilities in real-time, and that’s crucial for attaining a good security posture.
We’re also looking at software composition analysis (SCA). Everyone’s talking about SBOMs at the moment, and yes, we need SCA tooling to assess third-party libraries. We want to understand what vulnerabilities exist and identify possible licensing risks.
If you have a large budget, the idea of bug bounty programs can also provide value to your organization—of course, only if you have the budget for it. But at the end of the day, having tools isn’t enough. We all know that we need to automate security as much as possible and integrate these tools within the CI/CD pipeline.
Frank: Exactly where I was going. Excellent point—thank you for bringing that up, Matt. One of the things you mentioned was the three pillars: people, process, and technology. On the people side, when you incentivize developers, I remember we were in Istanbul and had a presentation where we announced the Security Champions program. What are some little things you can do to make it feel like a special role—something that’s recognized as an additional “hat” people wear?
Matt: Recognition is extremely important because people are people at the end of the day. Even small things, like providing merch, can make them feel special because they’re adding value to the organization. For example, during that presentation, one of our architects volunteered to be a Security Champion. She proudly wore the T-shirt and hat we handed out and kept them on all evening. That really showed me that we’re doing something good, and people are appreciating it. Even after the announcement, people reached out to me on Slack, saying, “Hey, thank you very much; we really appreciate this.” I’m seeing a lot of traction now—whether it’s with our AppSec engineer or others, the value is spreading. It’s really cool to see.
Dan: Yeah, so it’s quite literally an additional hat to wear, but one that people are wearing with pride. It’s working out pretty well—well done.
Drilling into some more of those pillars that you identified—technology being one—you listed a kind of grab bag of different techniques. We have DAST, which is, of course, central to our mission, but you also talked about SCA, bug bounties, and a variety of other tools. You qualified your statement by saying, “if you have enough money.” My question to you as a CISO is this: we don’t always operate with infinite resources, and I’m sure many of the CISOs listening to this podcast fully understand the challenges of doing their best with the resources they have.
If you had to choose—if you had to pick one technology pillar around which to build an AppSec program—what would you start with, and how would you expand? How would you spend your AppSec dollars, and in what order on different classes of tools?
Matt: That’s when the real CISO comes into play, right? It’s easy to throw money at problems, buying shiny tools and setting up a nice dashboard with all the vulnerabilities and correlations neatly presented. But as a real CISO, you need to do this with a budget that might not align with what you had envisioned in your roadmap.
If I had to choose from all these different pillars, I think technology would be the most important one for me. Personally, I would start with vulnerability management. Vulnerability management is critical because it addresses a number of things: real-time risk reduction, proactive and reactive risk reduction, and continuous protection. At the end of the day, you’re shipping new code into production, so you need tools that enable you to continuously monitor vulnerabilities and automate their mitigation.
Vulnerability management also covers a broad range of threats and the full attack surface. This includes using tools like SAST in combination with DAST and SCA. And we haven’t even mentioned other tools yet, like container scanning or IaC (infrastructure as code) scanning. Monitoring infrastructure within pipelines is extremely important these days.
Tools can be expensive, but vulnerability management is also cost-effective in many ways. The reason is that it scales with your targets. For example, if you’re scanning 10 targets today and 20 next year, you can adjust your investment accordingly. Additionally, vulnerability management ties into compliance. Whether you’re dealing with NIST, SOC 2, or ISO, it’s a foundational requirement. It’s like buying milk at the supermarket—it’s always something you need to do. Even if you’re not particularly invested in vulnerability management itself, you need it for that compliance certificate.
Dan: As a security company, we hold ourselves to high internal standards, but CISOs in organizations of varying sizes might be starting from scratch. What guidance would you give to someone taking their first step into the world of AppSec? What tool would you start with, and what has worked well for you in the past?
Matt: Whenever I’ve started an AppSec program, I’ve always implemented a DAST tool first. One reason is that there’s often a divide between developers and security, especially when you’re building the culture from scratch. DAST bridges that gap. It allows you and your team to manage vulnerabilities and gives you real-time visibility into your application’s attack surface.
For me, I’d always invest in DAST first, and then look at other tools later. DAST provides a lot of value, especially when dealing with applications that produce low false positives. It’s an essential starting point because it helps you address vulnerabilities in a way that’s both practical and impactful. And nowadays, we have API scanning as well. Many companies overlook APIs, but they’re a critical part of modern applications. Including API scanning is just as important.
Dan: One of the nice things about starting with DAST is the credibility it builds. When you bring a critical, confirmed vulnerability to a development team, it’s taken very seriously. With SAST, for instance, a vulnerability might spark a debate—someone might argue that it’s not exploitable and claim you’re wasting their time. SAST tools often struggle to understand the context of a vulnerability. But with DAST, you can use something as simple as a curl command to show the developer, “Look, I now have root on this machine.” It’s a very short discussion after that.
Matt: Exactly. It provides quick wins and helps address low-hanging fruit. If you need a solution to start building credibility and making an impact, DAST is the way to go.
Frank: Excellent, Matt. We’re going to shift again one more time. There’s something you brought up, and I think it’s crucial to be able to talk about, especially from your level and for a broader audience. You mentioned compliance a couple of different times, specifically with different references. Let’s focus on one of those.
I know that here, internally, you’ve gone through SOC 2 compliance and the processes involved. When we look at something like SOC 2, there are best practices and then there’s what’s essentially the minimum or what’s mandated. As a compliance expert, what are the actual guidelines and things that you’re looking for? How are these put into practice? What’s the most valuable advice you would give? For example, what are the challenges and things we’re looking at with SOC 2? How do we go about implementing these best practices to make sure we’re achieving our goals? What can be done specifically with SOC 2 as it might relate to AppSec? Let’s start with that first piece and go through some of the things you’ve gone through internally, and then maybe some quick hits for SOC 2 specifically.
Matt: SOC 2 can be a beast in its own regard. It’s actually quite interesting. I mean, I like SOC 2 because it attests to the logical controls that you have within the organization. Within SOC 2 itself, there are different trust criteria, and there are five criteria: security, availability, processing integrity, confidentiality, and privacy. Companies can opt to choose certain trust criteria, or they can choose to do all of these trust criteria.
In essence, there are quite a number of things related to AppSec when it comes to SOC 2. The first thing is that SOC 2 requires ongoing identification and mitigation of vulnerabilities. You have to do this in order to attest to this kind of control. Something to help sort this out would be to implement automated vulnerability scanning and integrate patch management into your CI/CD pipeline.
Another example is that SOC 2 mandates strict control over access to systems and data. What would you do there? You’d need to adopt role-based access control, integrate multi-factor authentication, and have proper reviews when it comes to access reviews. SOC 2 also requires data to be encrypted both in transit and at rest. What would you need to do there? You’d need to ensure proper key management systems are in place. You’d need to ensure that you have proper TLS 1.2 or 1.3 passing throughout your network. You’d also need to ensure proper encryption at rest when it comes to actual data sitting in your S3 buckets, for example, and in your databases.
Another area is that SOC 2 requires formal change management. You need to have proper security checks within your change management system. Again, I’m not talking about needing CAB meetings every week or anything like that. This isn’t FedRAMP, right? What we’re saying here is that there needs to be a paper trail showing that changes have been made, someone has vetted them, and they’ve been approved.
Obviously, there are different levels when it comes to all of these things. Why? Because security is a maturity model. Year after year, you’re actually improving your security infrastructure.
There are a lot of things. There’s also third-party management, which is quite a hot topic at the moment. This is another important area to ensure that you’re identifying and mitigating risks. Within AppSec itself, you need to have proper tooling to monitor third-party components for vulnerabilities.
Frank: If you had advice to give a CISO starting from zero with SOC 2, and if we’re putting a lens on this from an AppSec perspective, what are some internal wins or advice you’d give for someone starting from scratch? Is there a specific tool, guideline, or starting point that you’d recommend for building on?
Matt: Sure. I’ve done SOC 2 with just a DAST tool, for example. The idea is that within SOC 2—and even ISO—it doesn’t state that you need to have SAST or SCA running or anything like that. There’s a requirement, and you need to fill that requirement. DAST essentially fills in most of the requirements when it comes to SOC 2 compliance.
There’s also the governance part of it all. You need to start off by creating a north star—a framework or policy that guides how you’re going to do this. Then you work on implementing logical controls that adhere to that policy. For example, with role-based access control, you’d need a procedure or standard for how you’re doing RBAC, and you’d follow it through both on paper and with logical controls enforcing it.
This extends to things like third-party risk assessments and vendor management. You’d need a standard for how you’re doing this and ensure logical controls are enforcing that standard within your organization.
Frank: The supply chain area has been of definite interest and is growing in popularity.
Matt: Definitely. And in the same way we’ve had SBOMs in practice for a number of years, I tend to think there will soon be AI BOMs. Companies will need to understand, “These are the AI models we’re using,” and it will likely become a requirement. I feel this is coming soon. Maybe down the line, someone will listen to this podcast and say, “Matt was right—it did happen!”
Dan: Let it be known that on day of recording…
Frank: AI BOM!
Dan: So Matt, kind of zooming out for a moment—being a Chief Information Security Officer, it’s a position with a heavy crown. My question to you is, there’s got to be things about the job that keep you up at night. What is the hardest part of the job for you?
Matt: For me, it’s obviously managing limited resources and budgetary constraints. I think that’s the most difficult part because, at the end of the day, the threat landscape is always increasing, and the budget either stays the same or, in some cases, gets even smaller. You need to figure out how to do things in a way that ensures you’re using every dollar as effectively as possible. That, to me, is the hardest part of the job. In general, I think a lot of CISOs can attest to this. So yes, I would say that limited resources and budget constraints are the biggest challenges for CISOs overall.
Dan: And to end on a more positive note, for you, whether here at Invicti or elsewhere during your career, what’s been a victory in the CISO space that you’ve been most proud of?
Matt: For me, the biggest and coolest thing about being a CISO is achieving company buy-in. I think that’s the most important thing for your roadmap to be successful. That’s one of the reasons why I’m here at Invicti. There’s a lot of buy-in here. We’re in the security space, we all speak the same language, and I have a dedicated team.
I’m very happy with my team—I love my team—and I think we’re doing some really great, cool stuff here. So yes, company buy-in is definitely the key point for me.
Dan: Yeah, wonderful. Well, Matt, I just want to say thank you again for your time and for speaking with us today. It’s been a great conversation, and we hope to have you back on the podcast again sometime in the future.
Credits
- Fiction story and voiceover: Dan Murphy
- Discussion: Frank Catucci & Dan Murphy
- Special guest: Matthew Sciberras
- Voice of Alice: Alexa Rogers
- Production, music, editing, processing, voice of Bob: Zbigniew Banach
- Marketing support and promotion: Meaghan McBee
