How to catch and fix a Guice dependency injection issue using Sensei
The Sensei project itself has its own set of recipes that have built up over time. This blog post is an example of one of the scenarios the Sensei team built a recipe for. A misconfiguration of Guice, which led to a NullPointerException being reported at runtime during testing.
This can be generalized to many Dependency Injection scenarios where code is syntactically correct, but because the wiring configuration was incorrect, an error slips through.
This often happens when we are learning the technology, and we keep making the simple mistake of forgetting to wire things up. But this also happens to experienced professionals because, well... we all make mistakes, and we may not have Unit Tests to cover everything.
RunTime Exceptions from Incorrect Dependency Injection Wiring
The code below fails at runtime with a NullPointerException.
injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());
The code is syntactically correct but fails because we missed out a requestStaticInjection in our SystemOutModule configuration.
public class SystemOutModule extends AbstractModule {
@Override
protected void configure() {
binder().bind(ILineReporter.class).to(SystemOutReporter.class);
}
}
When we try to use the reporter, created using the Injector, it is not fully instantiated and we receive a NullPointerException when we call reportThisMany.
We may well have missed that in our code review, or we didn't have unit tests that triggered the dependency injection, and it slipped out into our build.
Warning Signs
In this case, there is a warning sign, the CountReporter has a static field annotated with @Inject but... the CountReporter class itself is package private.
In a complicated code base this could be a warning sign that the code is incorrect because the Module class configuring the bindings needs to be in the same package for this to work.
class CountReporter {
@Inject
private static ILineReporter reporter;
Another error that we made, which we might have picked up in a code review, is that we forgot to actually bind the fields in the SystemOutModule configure method.
binder().requestStaticInjection(CountReporter.class);
Had we written the requestStaticInjection code then the Syntax Error generated when trying to use the CountReporter would have alerted us to the simple error.
> 'reporters.CountReporter' is not public in 'reporters'. Cannot be accessed from outside package
Sadly. We forgot, and there were no syntactic warning signs in the code.
How could Sensei help?
We probably wouldn't use Sensei to pick up the missing requestStaticInjection since all our Guice configuration wiring would need to use that method, and we can't guarantee that all wiring is going to be as simple as this use-case.
We could write a Sensei rule to look for some warning signs that our code is not up to scratch.
In this case that would mean:
- Find any classes with @Inject annotated fields
- Where the classes are not public.
The above was the warning sign that they were unlikely to have been wired up.
By creating a recipe, then we will have a warning sign early, during the coding, and reduce the reliance on our pull requests or resolving our tech debt to allow us to add Unit Tests.
How to create a recipe?
The task I want to complete is:
- Create a recipe that matches fields annotated with @Inject which are in protected private classes
That should hopefully give us enough warning to identify any Modules using it and add the missing wiring code.
In my CountReporter class, I will use Alt+Enter to Create a new Recipe and I will start from scratch
I will name this and add a description:
Name: Guice: Injected Field Not Public
Description: If the Injected field is not public then the code might not be wired up
Level: Warning
The search I write looks for a class with a field annotated as Inject but which has not been scoped as public.
search:
field:
with:
annotation:
type: "com.google.inject.Inject"
in:
class:
without:
modifier: "public"
Fix
The QuickFix in the recipe will amend the injected class by changing the scope. But that is not the only code I have to change.
availableFixes:
- name: "Change class to public. Remember to also request injection on this class"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"
When the recipe is triggered I still have a manual step to perform in my code, adding the line containing requestStaticInjection to fully instantiate the object.
public class SystemOutModule extends AbstractModule {
@Override
protected void configure() {
binder().bind(ILineReporter.class).to(SystemOutReporter.class);
// instantiate via dependency injection
binder().requestStaticInjection(CountReporter.class);
}
}
I could potentially write another recipe to pick this up. I probably wouldn't do that unless forgetting to add the static injection became a semi-regular error that I made when coding.
Summary
If we ever find ourselves making a mistake with a common root pattern, then Sensei can help codify the knowledge around detecting and fixing the issue, and then hopefully, it won't slip through code reviews and into production.
Sometimes the recipes we write identify heuristic patterns i.e. matching them doesn't guarantee that there is a problem, but is likely that there is a problem.
Also, the recipes and QuickFixes that we write, don't have to be fully comprehensive, they need to be good enough that they help us identify and fix problems without being overcomplicated. Because when they become overcomplicated they become harder to understand and harder to maintain.
---
You can install Sensei from within IntelliJ using "Preferences \ Plugins" (Mac) or "Settings \ Plugins" (Windows) then just search for "sensei secure code".
The source code and recipes for this post can be found in the `sensei-blog-examples` repository in the Secure Code Warrior GitHub account, in the `guiceexamples` module.
https://github.com/securecodewarrior/sensei-blog-examples
An example scenario for a misconfiguration of Guice, which may lead to a NullPointerException being reported at runtime during testing.
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
The Sensei project itself has its own set of recipes that have built up over time. This blog post is an example of one of the scenarios the Sensei team built a recipe for. A misconfiguration of Guice, which led to a NullPointerException being reported at runtime during testing.
This can be generalized to many Dependency Injection scenarios where code is syntactically correct, but because the wiring configuration was incorrect, an error slips through.
This often happens when we are learning the technology, and we keep making the simple mistake of forgetting to wire things up. But this also happens to experienced professionals because, well... we all make mistakes, and we may not have Unit Tests to cover everything.
RunTime Exceptions from Incorrect Dependency Injection Wiring
The code below fails at runtime with a NullPointerException.
injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());
The code is syntactically correct but fails because we missed out a requestStaticInjection in our SystemOutModule configuration.
public class SystemOutModule extends AbstractModule {
@Override
protected void configure() {
binder().bind(ILineReporter.class).to(SystemOutReporter.class);
}
}
When we try to use the reporter, created using the Injector, it is not fully instantiated and we receive a NullPointerException when we call reportThisMany.
We may well have missed that in our code review, or we didn't have unit tests that triggered the dependency injection, and it slipped out into our build.
Warning Signs
In this case, there is a warning sign, the CountReporter has a static field annotated with @Inject but... the CountReporter class itself is package private.
In a complicated code base this could be a warning sign that the code is incorrect because the Module class configuring the bindings needs to be in the same package for this to work.
class CountReporter {
@Inject
private static ILineReporter reporter;
Another error that we made, which we might have picked up in a code review, is that we forgot to actually bind the fields in the SystemOutModule configure method.
binder().requestStaticInjection(CountReporter.class);
Had we written the requestStaticInjection code then the Syntax Error generated when trying to use the CountReporter would have alerted us to the simple error.
> 'reporters.CountReporter' is not public in 'reporters'. Cannot be accessed from outside package
Sadly. We forgot, and there were no syntactic warning signs in the code.
How could Sensei help?
We probably wouldn't use Sensei to pick up the missing requestStaticInjection since all our Guice configuration wiring would need to use that method, and we can't guarantee that all wiring is going to be as simple as this use-case.
We could write a Sensei rule to look for some warning signs that our code is not up to scratch.
In this case that would mean:
- Find any classes with @Inject annotated fields
- Where the classes are not public.
The above was the warning sign that they were unlikely to have been wired up.
By creating a recipe, then we will have a warning sign early, during the coding, and reduce the reliance on our pull requests or resolving our tech debt to allow us to add Unit Tests.
How to create a recipe?
The task I want to complete is:
- Create a recipe that matches fields annotated with @Inject which are in protected private classes
That should hopefully give us enough warning to identify any Modules using it and add the missing wiring code.
In my CountReporter class, I will use Alt+Enter to Create a new Recipe and I will start from scratch
I will name this and add a description:
Name: Guice: Injected Field Not Public
Description: If the Injected field is not public then the code might not be wired up
Level: Warning
The search I write looks for a class with a field annotated as Inject but which has not been scoped as public.
search:
field:
with:
annotation:
type: "com.google.inject.Inject"
in:
class:
without:
modifier: "public"
Fix
The QuickFix in the recipe will amend the injected class by changing the scope. But that is not the only code I have to change.
availableFixes:
- name: "Change class to public. Remember to also request injection on this class"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"
When the recipe is triggered I still have a manual step to perform in my code, adding the line containing requestStaticInjection to fully instantiate the object.
public class SystemOutModule extends AbstractModule {
@Override
protected void configure() {
binder().bind(ILineReporter.class).to(SystemOutReporter.class);
// instantiate via dependency injection
binder().requestStaticInjection(CountReporter.class);
}
}
I could potentially write another recipe to pick this up. I probably wouldn't do that unless forgetting to add the static injection became a semi-regular error that I made when coding.
Summary
If we ever find ourselves making a mistake with a common root pattern, then Sensei can help codify the knowledge around detecting and fixing the issue, and then hopefully, it won't slip through code reviews and into production.
Sometimes the recipes we write identify heuristic patterns i.e. matching them doesn't guarantee that there is a problem, but is likely that there is a problem.
Also, the recipes and QuickFixes that we write, don't have to be fully comprehensive, they need to be good enough that they help us identify and fix problems without being overcomplicated. Because when they become overcomplicated they become harder to understand and harder to maintain.
---
You can install Sensei from within IntelliJ using "Preferences \ Plugins" (Mac) or "Settings \ Plugins" (Windows) then just search for "sensei secure code".
The source code and recipes for this post can be found in the `sensei-blog-examples` repository in the Secure Code Warrior GitHub account, in the `guiceexamples` module.
https://github.com/securecodewarrior/sensei-blog-examples
The Sensei project itself has its own set of recipes that have built up over time. This blog post is an example of one of the scenarios the Sensei team built a recipe for. A misconfiguration of Guice, which led to a NullPointerException being reported at runtime during testing.
This can be generalized to many Dependency Injection scenarios where code is syntactically correct, but because the wiring configuration was incorrect, an error slips through.
This often happens when we are learning the technology, and we keep making the simple mistake of forgetting to wire things up. But this also happens to experienced professionals because, well... we all make mistakes, and we may not have Unit Tests to cover everything.
RunTime Exceptions from Incorrect Dependency Injection Wiring
The code below fails at runtime with a NullPointerException.
injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());
The code is syntactically correct but fails because we missed out a requestStaticInjection in our SystemOutModule configuration.
public class SystemOutModule extends AbstractModule {
@Override
protected void configure() {
binder().bind(ILineReporter.class).to(SystemOutReporter.class);
}
}
When we try to use the reporter, created using the Injector, it is not fully instantiated and we receive a NullPointerException when we call reportThisMany.
We may well have missed that in our code review, or we didn't have unit tests that triggered the dependency injection, and it slipped out into our build.
Warning Signs
In this case, there is a warning sign, the CountReporter has a static field annotated with @Inject but... the CountReporter class itself is package private.
In a complicated code base this could be a warning sign that the code is incorrect because the Module class configuring the bindings needs to be in the same package for this to work.
class CountReporter {
@Inject
private static ILineReporter reporter;
Another error that we made, which we might have picked up in a code review, is that we forgot to actually bind the fields in the SystemOutModule configure method.
binder().requestStaticInjection(CountReporter.class);
Had we written the requestStaticInjection code then the Syntax Error generated when trying to use the CountReporter would have alerted us to the simple error.
> 'reporters.CountReporter' is not public in 'reporters'. Cannot be accessed from outside package
Sadly. We forgot, and there were no syntactic warning signs in the code.
How could Sensei help?
We probably wouldn't use Sensei to pick up the missing requestStaticInjection since all our Guice configuration wiring would need to use that method, and we can't guarantee that all wiring is going to be as simple as this use-case.
We could write a Sensei rule to look for some warning signs that our code is not up to scratch.
In this case that would mean:
- Find any classes with @Inject annotated fields
- Where the classes are not public.
The above was the warning sign that they were unlikely to have been wired up.
By creating a recipe, then we will have a warning sign early, during the coding, and reduce the reliance on our pull requests or resolving our tech debt to allow us to add Unit Tests.
How to create a recipe?
The task I want to complete is:
- Create a recipe that matches fields annotated with @Inject which are in protected private classes
That should hopefully give us enough warning to identify any Modules using it and add the missing wiring code.
In my CountReporter class, I will use Alt+Enter to Create a new Recipe and I will start from scratch
I will name this and add a description:
Name: Guice: Injected Field Not Public
Description: If the Injected field is not public then the code might not be wired up
Level: Warning
The search I write looks for a class with a field annotated as Inject but which has not been scoped as public.
search:
field:
with:
annotation:
type: "com.google.inject.Inject"
in:
class:
without:
modifier: "public"
Fix
The QuickFix in the recipe will amend the injected class by changing the scope. But that is not the only code I have to change.
availableFixes:
- name: "Change class to public. Remember to also request injection on this class"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"
When the recipe is triggered I still have a manual step to perform in my code, adding the line containing requestStaticInjection to fully instantiate the object.
public class SystemOutModule extends AbstractModule {
@Override
protected void configure() {
binder().bind(ILineReporter.class).to(SystemOutReporter.class);
// instantiate via dependency injection
binder().requestStaticInjection(CountReporter.class);
}
}
I could potentially write another recipe to pick this up. I probably wouldn't do that unless forgetting to add the static injection became a semi-regular error that I made when coding.
Summary
If we ever find ourselves making a mistake with a common root pattern, then Sensei can help codify the knowledge around detecting and fixing the issue, and then hopefully, it won't slip through code reviews and into production.
Sometimes the recipes we write identify heuristic patterns i.e. matching them doesn't guarantee that there is a problem, but is likely that there is a problem.
Also, the recipes and QuickFixes that we write, don't have to be fully comprehensive, they need to be good enough that they help us identify and fix problems without being overcomplicated. Because when they become overcomplicated they become harder to understand and harder to maintain.
---
You can install Sensei from within IntelliJ using "Preferences \ Plugins" (Mac) or "Settings \ Plugins" (Windows) then just search for "sensei secure code".
The source code and recipes for this post can be found in the `sensei-blog-examples` repository in the Secure Code Warrior GitHub account, in the `guiceexamples` module.
https://github.com/securecodewarrior/sensei-blog-examples
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
The Sensei project itself has its own set of recipes that have built up over time. This blog post is an example of one of the scenarios the Sensei team built a recipe for. A misconfiguration of Guice, which led to a NullPointerException being reported at runtime during testing.
This can be generalized to many Dependency Injection scenarios where code is syntactically correct, but because the wiring configuration was incorrect, an error slips through.
This often happens when we are learning the technology, and we keep making the simple mistake of forgetting to wire things up. But this also happens to experienced professionals because, well... we all make mistakes, and we may not have Unit Tests to cover everything.
RunTime Exceptions from Incorrect Dependency Injection Wiring
The code below fails at runtime with a NullPointerException.
injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());
The code is syntactically correct but fails because we missed out a requestStaticInjection in our SystemOutModule configuration.
public class SystemOutModule extends AbstractModule {
@Override
protected void configure() {
binder().bind(ILineReporter.class).to(SystemOutReporter.class);
}
}
When we try to use the reporter, created using the Injector, it is not fully instantiated and we receive a NullPointerException when we call reportThisMany.
We may well have missed that in our code review, or we didn't have unit tests that triggered the dependency injection, and it slipped out into our build.
Warning Signs
In this case, there is a warning sign, the CountReporter has a static field annotated with @Inject but... the CountReporter class itself is package private.
In a complicated code base this could be a warning sign that the code is incorrect because the Module class configuring the bindings needs to be in the same package for this to work.
class CountReporter {
@Inject
private static ILineReporter reporter;
Another error that we made, which we might have picked up in a code review, is that we forgot to actually bind the fields in the SystemOutModule configure method.
binder().requestStaticInjection(CountReporter.class);
Had we written the requestStaticInjection code then the Syntax Error generated when trying to use the CountReporter would have alerted us to the simple error.
> 'reporters.CountReporter' is not public in 'reporters'. Cannot be accessed from outside package
Sadly. We forgot, and there were no syntactic warning signs in the code.
How could Sensei help?
We probably wouldn't use Sensei to pick up the missing requestStaticInjection since all our Guice configuration wiring would need to use that method, and we can't guarantee that all wiring is going to be as simple as this use-case.
We could write a Sensei rule to look for some warning signs that our code is not up to scratch.
In this case that would mean:
- Find any classes with @Inject annotated fields
- Where the classes are not public.
The above was the warning sign that they were unlikely to have been wired up.
By creating a recipe, then we will have a warning sign early, during the coding, and reduce the reliance on our pull requests or resolving our tech debt to allow us to add Unit Tests.
How to create a recipe?
The task I want to complete is:
- Create a recipe that matches fields annotated with @Inject which are in protected private classes
That should hopefully give us enough warning to identify any Modules using it and add the missing wiring code.
In my CountReporter class, I will use Alt+Enter to Create a new Recipe and I will start from scratch
I will name this and add a description:
Name: Guice: Injected Field Not Public
Description: If the Injected field is not public then the code might not be wired up
Level: Warning
The search I write looks for a class with a field annotated as Inject but which has not been scoped as public.
search:
field:
with:
annotation:
type: "com.google.inject.Inject"
in:
class:
without:
modifier: "public"
Fix
The QuickFix in the recipe will amend the injected class by changing the scope. But that is not the only code I have to change.
availableFixes:
- name: "Change class to public. Remember to also request injection on this class"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"
When the recipe is triggered I still have a manual step to perform in my code, adding the line containing requestStaticInjection to fully instantiate the object.
public class SystemOutModule extends AbstractModule {
@Override
protected void configure() {
binder().bind(ILineReporter.class).to(SystemOutReporter.class);
// instantiate via dependency injection
binder().requestStaticInjection(CountReporter.class);
}
}
I could potentially write another recipe to pick this up. I probably wouldn't do that unless forgetting to add the static injection became a semi-regular error that I made when coding.
Summary
If we ever find ourselves making a mistake with a common root pattern, then Sensei can help codify the knowledge around detecting and fixing the issue, and then hopefully, it won't slip through code reviews and into production.
Sometimes the recipes we write identify heuristic patterns i.e. matching them doesn't guarantee that there is a problem, but is likely that there is a problem.
Also, the recipes and QuickFixes that we write, don't have to be fully comprehensive, they need to be good enough that they help us identify and fix problems without being overcomplicated. Because when they become overcomplicated they become harder to understand and harder to maintain.
---
You can install Sensei from within IntelliJ using "Preferences \ Plugins" (Mac) or "Settings \ Plugins" (Windows) then just search for "sensei secure code".
The source code and recipes for this post can be found in the `sensei-blog-examples` repository in the Secure Code Warrior GitHub account, in the `guiceexamples` module.
https://github.com/securecodewarrior/sensei-blog-examples
Table of contents
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Resources to get you started
Setting the Standard: SCW Releases Free AI Coding Security Rules on GitHub
AI-assisted development is no longer on the horizon — it’s here, and it’s rapidly reshaping how software is written. Tools like GitHub Copilot, Cline, Roo, Cursor, Aider, and Windsurf are transforming developers into co-pilots of their own, enabling faster iteration and accelerating everything from prototyping to major refactoring projects.
Close the Loop on Vulnerabilities with Secure Code Warrior + HackerOne
Secure Code Warrior is excited to announce our new integration with HackerOne, a leader in offensive security solutions. Together, we're building a powerful, integrated ecosystem. HackerOne pinpoints where vulnerabilities are actually happening in real-world environments, exposing the "what" and "where" of security issues.
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
