Shauli Zacks
Published on: December 13, 2024
SafetyDetectives recently had the privilege of interviewing Maciej Krakowiak, one of the co-founders of at DSecure.me, a company dedicated to making robust cybersecurity accessible to startups, SMEs, and software houses. With roots in a team of engineers from the Santander group, Maciej has been instrumental in shaping DSecure.me’s evolution from a vulnerability management project to a leading provider of penetration testing and threat modeling services.
Maciej discusses the challenges SMEs face in cybersecurity, from budget constraints to the growing need for employee education. He also shares insights into the rise of open-source security solutions, the role of social engineering tests, and how DSecure.me helps clients build secure Software Development Life Cycles (SDLCs). Looking ahead, Maciej highlights emerging threats tied to AI plugins and the potential vulnerabilities businesses should prepare for as 2025 approaches.
What inspired you to co-found DSecure.me, and what is the company’s mission in the cybersecurity space?
I joined the project even before it had a formal name. Back then, we were a group of five engineers and cybersecurity analysts who met while working for the Santander group. Initially, our goal was to create a vulnerability management tool, which I’ll talk about in a moment. After a few, maybe several months, we formalized the company and started a business primarily focused on penetration testing.
I think our mission is mainly to show our clients that cybersecurity, as an added value to their products or services, isn’t something reserved only for the wealthiest companies. It’s possible to achieve a solid level of cybersecurity without spending hundreds of thousands of dollars on tools, specialists, and licenses. Most of our clients are startups or software houses, so in their case, the key is building awareness among software engineers and employees to ensure a high standard of security from the very early stages of their projects.
How does the Vulnerability Management Center (VMC) streamline vulnerability governance for security teams?
The overarching goal of the VMC was integration. While working on various projects, we encountered different tools, each with its own approach to presenting vulnerabilities and assessing the risks they posed. Most vendors use their proprietary metrics and risk assessment algorithms. We wanted to leverage well-known standards like CVSS (Common Vulnerability Scoring System) and CVE (Common Vulnerabilities and Exposures).
To achieve this, we needed to integrate open vulnerability databases, where CVSS is widely used; vulnerability scanners that report vulnerabilities using CVE; user asset databases to gather information about the user’s environment; and a communication channel to present integrated and normalized vulnerability data. The idea was to enable anyone with a scanning tool to build a solid and complete vulnerability management process, including identifying the owners of vulnerable assets, receiving alerts about critical vulnerabilities, and staying updated on emerging threats.
It was a noble idea, but like many stories, the scale of our undertaking was overwhelming.
I won’t deny that we had a very ambitious idea that was generally well-received by potential clients. In fact, we even had one implementation at Wrocław University of Science and Technology, where my business partner, Michał Walkowski, completed his PhD, which included deploying VMC as part of one of the projects. Unfortunately, we lacked the funding to continue development on our side, and we couldn’t sustain it with our own resources. As a result, we shifted the company’s focus to penetration testing, and the VMC project was ultimately released as open source. For now, it’s not being actively developed.
What unique challenges do small and medium-sized enterprises (SMEs) face in cybersecurity, and how does DSecure.me address them?
Unique challenges for SMEs in the context of cybersecurity primarily include limited budgets and the need to manage them effectively, insufficient human resources, and a lack of basic training among employees. Let me elaborate on each point for clarity.
Regarding budgets, the issue is quite straightforward. At DSecure.me, we’ve observed this trend from the very beginning. Most clients, both new and returning, request penetration tests in the fourth quarter or right at the start of the first quarter. This is directly tied to the fact that they need to allocate their remaining budget, and cybersecurity often comes to mind during this period. Unfortunately, this is an unflattering trend we’ve seen consistently over the years.
When it comes to human resources, SMEs typically focus on their product or service and efficient sales. Securing their assets often becomes a separate concern, not just in terms of the financial resources available but also in the context of staffing. Often, security teams in such companies consist of a so-called “one-man army,” a single individual responsible for everything. No matter how skilled and educated this person is, they can’t handle all the challenges of cybersecurity alone—they simply don’t have enough hours in the day to manage everything.
The third issue is education. The old mantra that “a security system is only as strong as its weakest link” is especially relevant here. The weakest link is often the human factor—an employee checking emails, answering phone calls, or picking up a USB drive found in the office restroom.
In all these areas, we can help our clients.
First, I believe, without false modesty, that we deliver excellent quality at a relatively low price. The penetration testing market is tough, and breaking into it is even tougher. One way to compete, of course, is through pricing. I think we’re relatively affordable compared to the high quality we provide.
Second, we often work with open-source solutions that can be implemented at a low cost to support those lone “one-man armies” by helping them prioritize the most critical issues and focus on addressing them. We can also assist small teams involved in software development. We do this by delivering clear and understandable penetration testing reports and helping to build a secure Software Development Life Cycle (SDLC). This includes implementing tools like SCA (Software Composition Analysis), conducting threat modeling sessions, and risk assessments aligned with the shift-left approach.
Finally, we collaborate with a fantastic startup specializing in simulated phishing campaigns and security awareness training. If I’m allowed to mention them here, their name is Secawa.com.
Can you share an example of a successful social engineering security test and its impact on the client’s security posture?
I don’t have any particularly unique stories about phishing. Most likely, nothing has happened to us that hasn’t already happened to other companies specializing in social engineering attacks. It doesn’t seem worthwhile to talk about rogue access points impersonating office Wi-Fi networks or dropping USB drives in parking lots or restrooms.
However, I do have an interesting anecdote about threat modeling. Threat modeling is typically done in the early stages of software development when we have various diagrams representing the software being built, user stories, use cases, and a general outline of the project. That’s when we can sit down with developers, review these diagrams, and brainstorm potential threats that might emerge in the software. We then analyze the risks and decide how to address them. Keep in mind, this is a very simplified explanation of the process.
Now, to the point: we were conducting threat modeling—not in the early stages of a project as is usually the case, but for a production-level, fully operational application. By asking a few targeted questions about how specific components worked, we managed to identify an SSRF (Server-Side Request Forgery) vulnerability in a feature that utilized one of the popular LLM engines. It was a serious vulnerability that could have potentially allowed for the takeover of the entire cloud environment.
How do you see the role of open-source solutions evolving in cybersecurity over the next few years?
I believe open-source solutions hold a strong position in cybersecurity. Many operate on a community vs. premium model, which means that companies not operating at the enterprise level can always find something suitable. It might be a free, self-hosted solution or a SaaS model with some level of paid support. I don’t see this situation changing anytime soon. The cybersecurity space has a massive community that places a strong emphasis on accessible knowledge and tools, like OWASP, for example.
Of course, using open-source solutions requires significant effort—they’re not plug-and-play tools that deliver results immediately. Many need customization, integration with processes and other tools, and, as a result, consume employee hours. However, if an SME has to choose between spending tens of thousands of dollars on a license or dedicating a few weeks of an engineer’s time to achieve similar results, the choice is usually obvious.
It’s essential to understand that open-source doesn’t mean inferior. Many premium or enterprise-class tools use open-source components at their core. What you’re often paying for is a customer success manager, 24/7 support, a Jira plugin, and a polished UI. 🙂
What key trends or threats should organizations prepare for as we move into 2025?
A huge number of companies are integrating some form of AI into their tools. AI plugins and assistants are popping up everywhere, even in online grocery stores, where they can find products, suggest items for specific recipes, or even compile a shopping cart for the customer. I believe these kinds of plugins will become a trending topic in the context of threats.
In an era of rapidly implemented features and short development cycles from one function to the next, integrating with an AI chat or LLM engine will likely lead to various kinds of abuse. These abuses might not be catastrophic, but they’ll probably be annoying enough to consume significant financial resources due to outages, exploitation, or simply repairing the damage to public opinion caused by a poor user interaction with the AI chat.
Don’t get me wrong—I have nothing against AI assistants; I use them myself. But from experience, I know that developers won’t be able to keep up with the business demands when it comes to testing edge cases and securing their AI integrations.
