An interview with Charlton Trezevant, Application Security Consultant at Xebia | Xpirit
Q: How important is security?
A: When selecting a company to work with, would you comfortably opt for one known for regular security breaches? Right. Security is a fundamental aspect of any business endeavor. Yet, even with the best intentions, things can still go pear-shaped due to a lack of knowledge, time, or resources. No matter the reason, avoiding shortcuts and investing in the right tools and processes is paramount to making security a first-class consideration in your development process.
Sadly, we often encounter organizations that are not ready or willing to change. Year after year, our tests will reveal the same issues, and they’re never resolved. Sometimes, companies use legacy software that’s difficult to update. Other times they rely on a third-party solution. However, if you know of a security risk, ask yourself…
… what will cost more, removing the dependency or dealing with the potential impact of it, like reputation damage, systems outage, or claims from customers?
Q: How are companies approaching security?
A: Imagine taking your car to a mechanic who hands you a sheet of paper and your keys, saying, “I looked at your engine. This is what’s wrong. Good luck.” That’s not very helpful. Unfortunately, we’re seeing a lot of companies take this approach to security — merely identifying the issues but blundering to solve them, and it’s time for a change.
Rather than focusing on the prevention of breaches and attacks, companies should think of security as a part of quality assurance.
Imagine you have a significant backlog of vulnerabilities, many of which are tied to authorization and authentication. Why not dig slightly deeper and look at how you handle authorization and authentication in your application? Did you build the tool yourself? Are you using a third-party solution? Why are you having so many problems in that particular area? Is there a common denominator? Should you offer better guidance or automated guardrails in your pipelines? When answering these questions, you’re using technical feedback to create a more effective process, inherently making your product safer.
Q: It sounds like security and development should form one team. How is that panning out in practice?
A: With a long history in development and a track record in security, I have found that those two worlds are at odds with each other in several ways. Without development backgrounds, security pros might struggle to understand the developer workflow, resulting in processes that do not meet the developers’ needs.
For example, as a pen tester, after testing a piece of software, I would present the company with a report with findings, which would eventually end up with the development team — dropping a bunch of tasks into their backlog long after they’ve finished working on the product. Now, they have to take all this information and figure out how to make these improvements. But, because it’s work they haven’t prepared for, they cannot just drop everything and get started. The result? Changes are not made or made at a very late stage.
The only way for application security to be effective is if companies put developers in the driver’s seat and make it a fantastic experience for them. How? By becoming extremely good at software development and DevOps. If you need help, partner with a company like ours!
Q: What are the most common security issues?
A: Firstly, with so many great tools available, it’s not hard to convince companies to adopt them. But the moment the tools start spitting out heaps of feedback, they have no idea what to do with that data. How do I look at this backlog and prioritize? How can I measure impact (i.e., are developers actually dealing with fewer security flaws and fixing them faster)? Secondly, security teams find it hard to consider developers — they often expect them to jump through endless hoops, which is a major blocker. Finally, companies need to make the transition. When DevOps was introduced, they were apprehensive. The same goes for (automating and integrating) security today. It’s a mindset shift that still needs to occur.
Q: How can we do better at managing security?
A: Stepping up automation is an excellent starting point. For instance, if your code base handles sensitive information, you can surround it with authorization checks, allowing you to condense the system’s security properties into a policy, which can be automatically enforced through scanning tools. Secondly, we can do better at vulnerability management in general. Imagine you have different types of scanning tools in place. Then, a penetration test reveals issues that these tools should be picking up. What do you do? One option is to work backwards and hand over a long list of tasks to the developers. Or, if, say, 10% of your total vulnerabilities are related to one element, why not consider taking some time to re-architect those components to eliminate a whole swath of issues from the backlog, leading to a more reliable and secure system?
Q: How can Xebia | Xpirit help?
A: At Xebia | Xpirit, we love to engineer new solutions and take novel approaches that empower companies to be more independent and work more efficiently. Instead of focusing on manual work and writing reports, we aim to create smooth-flowing processes and infrastructures that support autonomy.
Our approach depends on the customer’s goals. But, in general, we will follow these four steps:
- Automation: build different automated tools, deploy automation, and express policies to check security automatically.
- Integration: integrate all tools into updated vulnerability management processes, and help you understand the feedback they generate.
- Modernization: make automated tools part of your security process, and update legacy software to improve security.
- Maturity: help organizations achieve and maintain resilience through informed decision making, chaos experimentation, and modern security program design.
Q: What’s next in security?
A: AI-powered products will revolutionize the security industry! When trained on extensive code bases, AI tools can create entire pen test reports or open pull requests with actual fixes to that codebase on a more integrated and well-rounded level than automated tools and templates. This means, for example, that detection and response teams can rely on AI to complete many of their manual tasks, particularly in extracting details from datasets such as logs or long blocks of text.