try fix code layout

_posts/2023-02-15-jbang-reproducers.adoc

@@ -27,7 +27,12 @@ Or you (or Francesco) could just made a one-liner to run it with JBang.
 
 [source,bash]
 ----
-jbang --java 19 --deps org.openjdk.jmh:jmh-generator-annprocess:1.36 -m org.openjdk.jmh.Main -R=--enable-preview -R=--add-opens -R=java.base/java.lang=ALL-UNNAMED --javaagent=ap-loader@maxandersen=start,event=cpu,file=profile.html https://gist.github.com/franz1981/4234195ca0168f3833023b610d91ddff
+jbang --java 19 --deps org.openjdk.jmh:jmh-generator-annprocess:1.36 \
+-m org.openjdk.jmh.Main \
+ -R=--enable-preview -R=--add-opens \
+ -R=java.base/java.lang=ALL-UNNAMED \
+ --javaagent=ap-loader@maxandersen=start,event=cpu,file=profile.html \
+ https://gist.github.com/franz1981/4234195ca0168f3833023b610d91ddff
 ----
 
 If you run that, you will get the JMH benchmark numbers...
@@ -75,15 +80,18 @@ With that the gist would be directly runnable.
 
 I've made b1a6dd2019b359ec32b07f0599ee2d9e301a73e2[my own fork of the gist] to show it:
 
-```
+[source,bash]
+----
 jbang https://gist.github.com/maxandersen/d6571c2e637702fb55cd18783e5bff1b
-```
+----
 
 and to run it with async profiler you would just add the `--javaagent` part:
 
-```
-jbang --javaagent=ap-loader@maxandersen=start,event=cpu,file=profile.html https://gist.github.com/franz1981/4234195ca0168f3833023b610d91ddff
-```
+[source,bash]
+----
+jbang --javaagent=ap-loader@maxandersen=start,event=cpu,file=profile.html \
+https://gist.github.com/franz1981/4234195ca0168f3833023b610d91ddff
+----
 
 == Bonus tips
 
@@ -93,9 +101,10 @@ This uses a gist, but could also been any .java or .jar file locally or on the w
 
 For example if you wanted to generate flamegraph for Quarkus CLI you would do:
 
-```
+[source,bash]
+----
 jbang --javaagent=ap-loader@maxandersen=start,event=cpu,file=profile.html quarkus@quarkusio
-```
+----
 
 This is loading  the agent on the `quarkus@quarkusio` alias which behind the scene points to a jar in maven central. 
 

_posts/2024-04-23-java-has-the-most-vulnerabilities.adoc

@@ -0,0 +1,49 @@
+= Yes! Java services obviouslhave the most vulnerabilities
+:page-layout: post
+ifdef::env-github,env-browser,env-vscode[:imagesdir: ../] 
+
+== Introduction
+
+I've recently come across a piece of media coverage that has, once again, put Java in the spotlight for all the wrong reasons. The narrative around Java being the most vulnerable language has been circulating, as if that is a surprise and that it is bad news. But is it really?
+
+== The Infoworld Article
+
+A https://www.infoworld.com/article/3715264/java-services-hit-hardest-by-third-party-vulnerabilities-says-report.html[recent article by Infoworld] took a first headline from DataDog's recent https://www.datadoghq.com/state-of-devsecops/[State of DevOp] report, claiming that Java services are hit hardest by third-party vulnerabilities.
+
+== The Misleading Headline
+
+DataDog's report does state as its first bullet point that Java services are hit hardest by third-party vulnerabilities. But does that mean Java is inherently less secure than other languages? Not necessarily.
+
+It's no secret that Java, much like Windows in the realm of operating systems, often scores high in vulnerability counts. Have you ever stopped to wonder why? The answer is quite straightforward: _usage_. Java's widespread adoption makes it a prime target, but that doesn't inherently make it less secure.
+
+Below is an image from the DataDog report that kicked off this discussion. It shows the number of vulnerabilities by language, with Java leading the pack. But does this mean Java is less secure than other languages? Not necessarily. Just shows it has more vulnerabilities reported, which could be due to its popularity and the number of eyes on it.
+
+.Language Vulnerability Statistics (source: Datadog)
+image::https://imgix.datadoghq.com/img/blog/state-of-devsecops/state-of-devsecops-2024/fact-1a.png?ch=Width%2cDPR%2cSave-Data&fm=png&auto=format&fit=max&w=1120&h=586&dpr=2&q=75[Java Vulnerability Statistics]
+
+
+
+== A Closer Look at the Report
+
+The report makes a couple of points worth discussing:
+
+. Java is the platform "hit hardest" in terms of the number of deployments with recorded CVEs.
+. A small portion of identified vulnerabilities are actually worth prioritizing.
+
+=== The Issue with CVE Reporting
+
+Anyone can report a CVE, leading to a significant number of reports that, frankly, don't hold water. My experience working on @QuarkusIO has shown me that the context often dictates the severity of a vulnerability, making many reported CVEs irrelevant to most deployments.
+
+== The Real Concern
+
+The overreliance on scanners and reports can be misleading. It's crucial to maintain a proactive stance towards security, upgrading systems early and often. Java's stability and backward compatibility, coupled with an ever-growing toolkit for developers, make it an excellent choice for secure, adaptable systems.
+
+== Conclusion
+
+Java's popularity and utility have made it a target for criticism, but it's important to look beyond the headlines. The platform's robust ecosystem and commitment to security make it a reliable choice for developers worldwide.
+
+We must encourage the community to stay informed and vigilant, ensuring that Java continues to be both popular and secure.
+
+== Stay Connected
+
+For more insights and updates, follow me on Twitter at @YourTwitterHandle.