#Log4j

[jpmellojr]

Think Log4j is a wrap? Think again

Three years after its discovery, Log4Shell remains one of the software flaws that are most used by threat actors, a new report released by Cato Networks has found. https://jpmellojr.blogspot.com/2024/08/think-log4j-is-wrap-think-again.html

[edwardos]

I think the verdict is now very clear about when the Minecraft Silver Age ended.

[english-mace]

linux is not. magically free of the Dependencies curse, tho.

like I respect the moxie & mod-ability of an open OS as much as the next bigtech girlie but it very much is still Computer

it's honestly nuts to me that critical infrastructure literally everywhere went down because everyone is dependent on windows and instead of questioning whether we should be letting one single company handle literally the vast majority of global technological infrastructure, we're pointing and laughing at a subcontracted company for pushing a bad update and potentially ruining themselves

like yall linux has been here for decades. it's stable. the bank I used to work for is having zero outage on their critical systems because they had the foresight to migrate away from windows-only infrastructure years ago whereas some other institutions literally cannot process debit card transactions right now.

global windows dependence is a massive risk and this WILL happen again if something isn't done to address it. one company should not be able to brick our global infrastructure.

[cyber-sec]

Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild

Source: https://blog.talosintelligence.com/apache-log4j-rce-vulnerability/

[jadeghosthill]

2b2t players will post videos about "Minecraft's most DANGEROUS bug" and it's actually just a really niche glitch that lets you find someone's base and the only reason its dangerous is because 2b2t players are mentally ill

good for them but log4j existed there are more dangerous bugs i think

[aktionfsa-blog-blog]

Gesundheitsdaten nur bedingt sicher

KIM = Kaos in der Medizin

Eigentlich sollte KIM ein sicherer E-Mail Service für die Medizin, also die Kommunikation zwischen Krankenkassen und Ärzten sein. Etwas ähnliches gibt es auch seit Jahren im Bereich der Justiz für Gerichte und Anwälte. Insofern handelt es sich nicht um die grandiosiste Innovation. 

Trotzem ging es schief. Wie auf dem 37. CCC Kongress in Hamburg von dem Münsteraner Sicherheitsforscher Christoph Saatjohann vom Fraunhofer-Institut für Sichere Informationstechnologie (SIT) in Münster und Sebastian Schinzel berichtet wurde, haben insgesamt acht Krankenkassen durch die Gematik den gleichen S/MIME-Key erhalten. Sichere E-Mail beruht auf dem seit den 80-iger Jahren von Phil Zimmermann entwickelten Public-Private-Key Verfahren. In öffentlichen Einrichtungen geschieht das nach dem Standard X.509, während im privaten Umfeld Jede/r seine Schlüsselpaare selbst generieren kann.

Wenn jedoch die Zertifizierungsstellen (CAs) für verschiedene Akteure die gleichen Schlüssel verteilen, dann war es das mit der Sicherheit sensibler medizinischer Daten. Das ist der GAU in der PKI - der Public Key Infrastructure.

Laut den Sicherheitsforschern hatten, wie Heise.de schreibt, einmal drei Krankenkassen denselben im September 2021 ausgestellten Schlüssel, bei einem zweiten Schlüssel fünf. 28% der Bürgerinnen und Bürger seien über diese acht Krankenkassen versichert gewesen. Dieser Vorfall war nicht der erste mit KIM. 2022 wurde eine Log4J-Schwachstelle im KIM-Clientmodul von T-Systems gefunden.

Künftig werden die Schlüssel nun monatlich auf Dopplungen geprüft.

Mehr dazu bei https://www.heise.de/news/37C3-Schluessel-fuer-E-Mail-Dienst-KIM-fuer-das-Medizinwesen-mehrfach-vergeben-9583275.html

Kategorie[21]: Unsere Themen in der Presse Short-Link dieser Seite: a-fsa.de/d/3y7 Link zu dieser Seite: https://www.aktion-freiheitstattangst.org/de/articles/8633-20231229-gesundheitsdaten-nur-bedingt-sicher.html

[queerbogbitch]

botnets like mirai are pretty prolific, people just don't notice because nobody cares about securing routers and IoT

the modern internet needs a new mega virus. weve gone too long without having a named virus that takes out a major % of computers

[ericvanderburg]

Still Running Vulnerable Log4j Instances? 

http://securitytc.com/TLdf9j

[weetechsolution]

Top WebApp Security Checklist for Businesses in the USA (2025)

In today’s digital-first world, web applications are the backbone of most business operations—from e-commerce to customer portals, CRMs, and more. However, with increasing cyber threats, securing your web applications is not optional; it's critical. Especially for businesses operating in the USA, where data breaches can lead to legal penalties, loss of customer trust, and significant financial setbacks.

This guide outlines a comprehensive WebApp Security Checklist tailored for businesses in the USA to ensure robust protection and compliance with modern security standards.

1. Use HTTPS with a Valid SSL Certificate

Secure Socket Layer (SSL) certificates are fundamental. HTTPS encrypts the data exchanged between the user and your application, ensuring it remains private.

Purchase and install a trusted SSL certificate.

Redirect all HTTP traffic to HTTPS.

Regularly renew and monitor the validity of your SSL certificate.

Fact: Google flags HTTP sites as “Not Secure,” impacting SEO and user trust.

2. Implement Strong Authentication & Access Controls

Weak login systems are a hacker’s playground. Use:

Multi-Factor Authentication (MFA): Add extra layers beyond passwords.

Role-Based Access Control (RBAC): Ensure users only access what’s necessary.

Session Management: Set session expiration limits and auto-logout on inactivity.

Bonus Tip: Use OAuth 2.0 or OpenID Connect for secure federated authentication.

3. Sanitize and Validate All User Inputs

Most web attacks like SQL Injection and XSS stem from unsanitized user inputs. To prevent this:

Sanitize inputs on both client and server sides.

Use prepared statements and parameterized queries.

Escape special characters in output to prevent script injections.

Best Practice: Never trust user inputs — even from authenticated users.

4. Regularly Update Dependencies and Frameworks

Outdated plugins, libraries, or frameworks can be exploited easily.

Use dependency management tools like npm audit, pip-audit, or OWASP Dependency-Check.

Enable automatic updates where possible.

Avoid deprecated plugins or unsupported software.

Real Example: The infamous Log4j vulnerability in 2021 exposed millions of apps worldwide.

5. Conduct Regular Vulnerability Scans and Penetration Testing

Security is not a one-time fix. It's a continuous process.

Schedule monthly or quarterly vulnerability scans.

Hire ethical hackers for real-world pen testing.

Fix discovered issues immediately and re-test.

🔍 Tools to Use: Nessus, Burp Suite, OWASP ZAP.

6. Implement Secure APIs

With APIs powering most modern web apps, they’re a common attack vector.

Authenticate API users with tokens (JWT, OAuth).

Rate-limit API calls to avoid abuse.

Use API gateways for logging and security enforcement.

Extra Tip: Never expose sensitive internal APIs to the public internet.

7. Data Encryption at Rest and in Transit

Whether storing user passwords, payment info, or PII — encryption is essential.

Encrypt sensitive data in the database using AES-256 or better.

Avoid storing passwords in plain text — use hashing algorithms like bcrypt.

Always encrypt data transfers via HTTPS or secure VPN tunnels.

Compliance: Required under data protection laws like HIPAA, CCPA, and PCI-DSS.

8. Monitor Logs & Set Up Intrusion Detection

Monitoring can alert you to threats in real-time.

Use centralized logging systems like ELK Stack or Splunk.

Implement intrusion detection systems (IDS) like Snort or OSSEC.

Set up alerts for unusual activities like multiple failed logins.

Tip: Review logs weekly and set up daily summaries for admins.

9. Backup Regularly & Prepare a Disaster Recovery Plan

Cyberattacks like ransomware can lock you out of your app.

Schedule automatic daily backups.

Store backups offsite or in the cloud (with encryption).

Test your disaster recovery plan quarterly.

Pro Tip: Use versioned backups to roll back only the infected data.

10. Comply with Data Privacy Regulations

For businesses in the USA, compliance isn't just good practice — it's the law.

If you handle health data → HIPAA compliance is mandatory.

Selling to California residents → comply with CCPA.

Accepting payments? → follow PCI-DSS requirements.

Reminder: Non-compliance can lead to heavy penalties and lawsuits.

11. Educate Your Team

The weakest link is often human error.

Train employees on phishing and social engineering attacks.

Enforce strong password policies.

Run annual cybersecurity awareness programs.

Result: A well-trained team is your first line of defense.

12. Use Web Application Firewalls (WAFs)

WAFs provide an extra layer of protection.

Block malicious traffic before it reaches your server.

Protect against DDoS, brute force, and zero-day attacks.

Use cloud-based WAFs like Cloudflare, AWS WAF, or Imperva.

Bonus: Easily deployable and scalable with your infrastructure.

Conclusion

For U.S.-based businesses, web application security should be a strategic priority — not a checkbox. With cyberattacks growing in complexity and volume, following a thorough security checklist is vital to protect your data, users, and brand reputation.

At the end of the day, your web application is only as secure as its weakest link. Make sure there isn’t one.

Ready to Secure Your WebApp?

If you're looking for expert support to secure or build a robust, secure web application, WeeTech Solution is here to help. Get in touch with our development and cybersecurity team today!

[jpmellojr]

Cloudflare report: Log4j remains top target for attacks in 2023

Log4j remained a top attack vector for threat actors in 2023, while a new vulnerability, HTTP/2 Rapid Reset is emerging as a significant threat to organizations, according to Cloudflare’s annual “Year in Review” report. https://jpmellojr.blogspot.com/2023/12/cloudflare-report-log4j-remains-top.html

[threetrenchcoatsinatrenchcoat]

on the one hand it's kinda annoying that our digital and physical lives are coated with ads set on making us feel incomplete, for companies that then have unchecked censorship rights on their surrounding content, and political campaigns are won by the most advertised candidate, and the surveillance state created by the amount of our data being sold is used for voter suppression and stalkers, and it's burning down the planet with direct online advertising alone producing the equivalent of up to 159 metric tons of carbon dioxide emissions a year,

but hey, the internet couldn't possibly ever be run by volunteers.

except it is. right now.

XZ Utils and OpenSSL and Log4j and many projects like them are volunteer-led--OpenSSL in particular is almost entirely managed by two men named Steve. the projects have some funding sometimes but the people who fix stuff when it breaks usually aren't paid and all have other full-time jobs. we know this because it's happened, i only heard about these specific services because they've all recently had vulnerabilities that had to wait for volunteers to get off work or for one of the Steves to pause his vacation. and some big companies were relying on them.

big companies like linux and facebook and google and microsoft and amazon web services and twitter and cloudflare and apple and intuit and paypal and tumblr. y'know, basically the internet. so much of their infrastructure is volunteer code right now. if they don't need all that ad money and user data we're netting them, what are we actually getting in return?

what if we just turned the ads off? what if we just turned the ads off? what if we just turned the ads off?

what if the next time google wants to collect data to sell for drone strikes they have to fill out a grant proposal and put the notion on a ballot?

love when ppl defend the aggressive monetization of the internet with "what, do you just expect it to be free and them not make a profit???" like. yeah that would be really nice actually i would love that:)! thanks for asking

[lovingcupcakeartisan]

Software Composition Analysis Market Report: Unlocking Growth Potential and Addressing Challenges

United States of America – Date – 26/06/2025 - The Insight Partners is proud to announce its newest market report, "Software Composition Analysis Market: An In-depth Analysis of the Software Composition Analysis Market". The report provides a holistic view of the Software Composition Analysis market and describes the current scenario as well as growth estimates for Software Composition Analysis during the forecast period.

Overview of Software Composition Analysis Market

There has been some development in the Software Composition Analysis market, such as growth and decline, shifting dynamics, etc. This report provides insight into the driving forces behind this change: technological advancements, regulatory changes, and changes in consumer preference.

Key findings and insights

Market Size and Growth

Historical Data: The Software Composition Analysis market is estimated to reach US$ XX million by 2031, with a CAGR of XX%. These estimates provide valuable insights into the market's dynamics and can inform future projections.

Key Factors Affecting the Software Composition Analysis Market:

Ubiquitous Adoption of Open-Source Software (OSS): A staggering percentage of modern applications are built using open-source components. While OSS accelerates development and offers cost efficiencies, it also introduces a vast attack surface and complex licensing obligations. SCA is indispensable for gaining visibility into and managing this extensive use of OSS.

Escalating Software Supply Chain Attacks: Cyberattacks increasingly target the software supply chain, exploiting vulnerabilities in open-source components and third-party libraries. High-profile incidents (like Log4j) have highlighted the critical need for SCA to identify, track, and mitigate these risks throughout the software development life cycle (SDLC).

Strict Regulatory and Compliance Requirements: Governments and industry bodies are enacting more stringent regulations regarding software security, data privacy, and intellectual property. Compliance mandates like the U.S. Executive Order on Cybersecurity, GDPR, HIPAA, and industry-specific standards (e.g., for automotive or healthcare) compel organizations to have a comprehensive understanding of their software's composition and its associated risks.

Shift Left Security and DevSecOps Adoption: The trend of "shifting left" in security, integrating security practices earlier into the development pipeline (DevSecOps), is a major driver. SCA tools, being automated and capable of integration into CI/CD workflows, enable developers to identify and remediate vulnerabilities and license issues before they reach production, saving time and cost.

Spotting Emerging Trends:

Technological Advancements:

AI and Machine Learning (AI/ML) for Advanced Vulnerability Detection: AI/ML is moving beyond known vulnerabilities to detect zero-day exploits or previously unknown vulnerabilities (N-day vulnerabilities) by analyzing code patterns and behaviors. This includes predictive analytics for identifying future risks based on past trends.

Contextual Vulnerability Analysis: SCA tools are evolving to understand the reachability and exploitability of vulnerabilities in open-source components. This means focusing on vulnerabilities that are actually executable in the application's runtime context, reducing "alert fatigue" and prioritizing real risks.

Changing Consumer Preferences (Developer and Security Team Demand):

Developer-Centric Security: Developers want security tools that integrate seamlessly into their existing workflows (IDEs, CI/CD) and provide fast, actionable feedback without disrupting their productivity. "Shift smart" over just "shift left" – fixing issues quickly and easily at any point in the SDLC.

Actionable Insights over Raw Data: Customers are overwhelmed by vulnerability alerts. They prefer SCA solutions that provide prioritized, contextualized, and actionable insights, focusing on exploitable vulnerabilities and offering clear remediation guidance.

Growth Opportunities:

Deepening Integration into DevOps/DevSecOps: The market will grow by providing more seamless, automated, and non-intrusive integration of SCA into every stage of the CI/CD pipeline, making it a natural part of the developer workflow rather than an afterthought.

Focus on Cloud-Native Security: As organizations accelerate their shift to cloud-native architectures, opportunities abound for SCA solutions specifically designed to analyze and secure container images, Kubernetes deployments, serverless functions, and other cloud-native components.

Expansion into New Verticals and SMEs: While BFSI and IT are mature, significant growth opportunities exist in sectors like healthcare, automotive, industrial IoT, and critical infrastructure, especially as they digitalize and adopt more open-source. Tailored, more accessible (often cloud-based) solutions for SMEs will also drive growth.

Advanced AI/ML Capabilities: Vendors who can effectively leverage AI/ML for more intelligent vulnerability detection (e.g., exploitability analysis, zero-day prediction), automated remediation, and context-aware insights will capture significant market share.

Conclusion

The Software Composition Analysis Market: Global Industry Trends, Share, Size, Growth, Opportunity, and Forecast Software Composition Analysis 2023-2031 report provides much-needed insight for a company willing to set up its operations in the Software Composition Analysis market. Since an in-depth analysis of competitive dynamics, the environment, and probable growth path are given in the report, a stakeholder can move ahead with fact-based decision-making in favor of market achievements and enhancement of business opportunities.

About The Insight Partners

The Insight Partners is among the leading market research and consulting firms in the world. We take pride in delivering exclusive reports along with sophisticated strategic and tactical insights into the industry. Reports are generated through a combination of primary and secondary research, solely aimed at giving our clientele a knowledge-based insight into the market and domain. This is done to assist clients in making wiser business decisions. A holistic perspective in every study undertaken forms an integral part of our research methodology and makes the report unique and reliable.

[vijaysethupati]

 Debugging Full Stack Apps: Common Pitfalls and Fixes

If you’ve ever stared at your code wondering why nothing works—while everything looks fine—you’re not alone. Debugging Full Stack Apps: Common Pitfalls and Fixes is something every full stack developer becomes intimately familiar with, usually the hard way. Debugging can feel like detective work: sifting through clues, spotting red herrings, and slowly putting the pieces together.

Whether you’re knee-deep in React components or wrangling with PostgreSQL queries, bugs don’t discriminate. They can lurk in the front end, back end, or anywhere in between.

Here’s a look at common pitfalls when debugging full stack apps—and practical ways to fix them.

1. Miscommunication Between Front End and Back End

One of the most common issues arises from how the front end communicates with the back end. Sometimes, they seem to speak different languages.

Common Symptoms:

API calls returning unexpected results (or nothing at all)

Mismatched data formats (e.g., sending a string where the server expects a number)

CORS errors that mysteriously appear during deployment

Fixes:

Always double-check your request headers and response formats.

Use tools like Postman or Insomnia to simulate API requests separately from your front-end code.

Implement consistent API response structures across endpoints.

As a full stack developer, ensuring clean contracts between layers is essential. Don’t assume—it’s better to over-communicate between parts of your app than to be left scratching your head at 2 AM.

2. Version Mismatches and Package Conflicts

Let’s face it: dependency hell is real.

Common Symptoms:

Front-end not rendering after an npm install

Server crashing due to deprecated methods

Mysterious breaking changes after updating a package

Fixes:

Lock dependencies using a package-lock.json or yarn.lock file.

Regularly audit your packages with tools like npm audit or yarn audit.

Avoid updating all dependencies at once—do it incrementally and test thoroughly.

Even the most seasoned full stack developer gets tripped up here. Being methodical with updates and isolating changes can save you hours of frustration.

3. State Management Gone Wrong

If your app behaves inconsistently, the problem might be state management.

Common Symptoms:

UI doesn’t reflect expected changes

Data seems to "disappear" or update out of sync

Components re-render unnecessarily

Fixes:

Use debugging tools like Redux DevTools or Vuex Inspector to trace changes.

Store only essential data in global state—leave UI state local whenever possible.

Be cautious with asynchronous operations that update state (e.g., API calls).

Mastering state is part art, part science. As a full stack developer, understanding both front-end and back-end data flow is key to smooth state management.

4. Overlooking Server Logs and Console Errors

It’s easy to jump straight into the code—but logs often contain the breadcrumbs you need.

Common Symptoms:

500 errors with no clear origin

"Something went wrong" messages with no context

App crashing without traceable bugs

Fixes:

Always monitor the back-end logs (use console.log, but also tools like Winston or Log4js for structured logging).

Use browser developer tools to inspect network requests and console outputs.

Integrate error-tracking tools like Sentry or LogRocket.

A skilled full stack developer knows that logs are like black box recorders for your app—ignore them at your own peril.

5. Deployment-Specific Bugs

Your app runs perfectly locally—but breaks in production. Sound familiar?

Common Symptoms:

Missing environment variables

Static assets not loading

Database connection failures post-deployment

Fixes:

Use .env files carefully and securely manage environment-specific configs.

Ensure your build process includes all required assets.

Test your deployment process using staging environments before going live.

Every full stack developer eventually realizes: what works in dev doesn’t always work in prod. Always test in conditions that mimic your live environment.

Final Thoughts

Debugging Full Stack Apps: Common Pitfalls and Fixes isn’t just about technical skills—it’s about mindset. It’s easy to get overwhelmed when something breaks, but remember: every bug you squash teaches you something new.

Here are some golden rules to live by:

Reproduce the bug consistently before trying to fix it.

Break down the problem layer by layer.

Ask for a second pair of eyes—sometimes, fresh perspective is all it takes.

Being a full stack developer is like being a bridge-builder—you connect front end and back end, logic and interface, user and server. And in between, debugging is your glue.

So next time you hit a wall, take a breath, grab a coffee, and dig in. You’ve got this.

[fromdevcom]

Splunk is a popular choice for log analytics. I am a java developer and really love to use splunk for production analytics. I have used splunk for more than 5 years and like its simplicity. This article is a list of best practices that I have learned from good splunk books and over my splunk usage in everyday software projects. Most of the learnings are common for any software architect however it becomes important to document them for new developers. This makes our life easier in maintaining the software after it goes live in production. Almost any software becomes difficult change after its live in production. There are some many things you may need to worry about. Using these best practices while implementing splunk in your software will help you in long run. First Thing First : Keep Splunk Logs Separate Keep splunk log separate from debug / error logs. Debug logs can be verbose. Define a separate splunk logging file in your application. This will also save you on licensing cost since you will not index unwanted logs. Use Standard Logging Framework Use existing logging framework to log to splunk log files. Do not invent your own logging framework. Just ensure to keep the log file separate for splunk. I recommend using Asynchronous logger to avoid any performance issues related to too much logging. Some popular choice of logging frameworks in Java are listed below Log4j  SLF4J Apache commons logging Logback Log In KEY=VALUE Format Follow Key=Value format in splunk logging - Splunk understands Key=Value format, so your fields are automatically extracted by splunk. This format is also easier to read without splunk too. You may want to follow this for all other logs too. Use Shorter KEY Names Keep the key name short - preferable size should be less than 10 characters. Though you may have plenty of disc space. Its better to keep a tap on how much you log since it may create performance problems in long run. At the same time keep them understandable. Use Enums For Keys Define a Java Enum for SplunkKeys that has Description of each key and uses name field as the splunk key.  public enum SplunkKey TXID("Transaction id"); /** * Describes the purpose of field to be splunked - not logged */ private String description; SplunkKey(String description) this.description = description; public String getDescription() return description; Create A Util Class To Log In Splunk Define a SplunkAudit class in project that can do all splunk logging using easy to call methods. public class SplunkAudit private Map values = new HashMap(); private static ThreadLocal auditLocal = new ThreadLocal(); public static SplunkAudit getInstance() SplunkAudit instance = auditLocal.get(); if (instance == null) instance = new SplunkAudit(); auditLocal.set(instance); return instance; private SplunkAudit() public void add(SplunkKey key, String message) values.put(key.name(), message); public void flush() StringBuilder fullMessage = new StringBuilder(); for (Map.Entry val : values.entrySet()) fullMessage.append(val.getKey()); fullMessage.append("="); fullMessage.append(val.getValue()); fullMessage.append(" "); //log the full message now //log.info(fullMessage); Collect the Splunk Parameters (a collection of key,value pairs ) in transaction and log them at the end of transaction to avoid multiple writes. Use Async Log Writer  Its recommended to use async logger for splunk logs. Async logging will perform logging in a separate thread. Below are some options  Async Logger Appender for Log4j Logback Async Appender  Setup Alerts Setup Splunk queries as alerts - get automatic notifications. Index GC Logs in Splunk Index Java Garbage Collection Logs separately in splunk.

The format of GC log is different and it may get mixed with your regular application logs. Therefore its better to keep it separate. Here are some tips to do GC log analytics using splunk. Log These Fields Production logs are key to debug problems in your software. Having following fields may always be useful. This list is just the minimum fields, you may add more based on your application domain. ThreadName  Most important field for Java application to debug and identify multithreading related problems. Ensure every thread has a logical name in your application. This way you can differentiate threads. For example transaction threads and background threads may have different prefix in thread name. Ensure to give a unique id for each thread. Its super easy to set thread names in java. One line statement will do it. Thread.currentThread().setName(“NameOfThread-UniqueId”) Thread Count  Print count of threads at any point in time in JVM. Below one liner should provide you java active thread count at any point in JVM. java.lang.Thread.activeCount() Server IP Address Logging the server IP address become essential when we are running the application on multiple servers. Most enterprise application run cluster of servers. Its important to be able to differentiate errors specific to a special server.  Its easy to get IP address of current server. Below line of code should work for most places (unless the server has multiple ip addresses) InetAddress.getLocalHost().getHostAddress() Version Version of software source from version control is important field. The software keeps changing for various reasons. You need to be able to identify exact version that is currently live on production. You can include your version control details in manifest file of deployable war / ear file. This can be easily done by maven. Once the information is available in your war/ear file, it can be read in application at runtime and logged in splunk log file. API Name Every application performs some tasks. It may be called API or something else. These are the key identifier of actions. Log unique API names for each action in your application. For example API=CREATE_USER API=DELETE_USER API=RESET_PASS Transaction ID Transaction id is a unique identifier of the transaction. This need not be your database transaction id. However you need a unique identifier to be able to trace one full transaction. User ID - Unique Identifier User identification is important to debug many use cases. You may not want to log user emails or sensitive info, however you can alway log a unique identifier that represents a user in your database. Success / Failure of Transaction Ensure you log success or failure of a transaction in the splunk. This will provide you a easy trend of failures in your system. Sample field would look like TXS=S (Success transaction) TXS=F (Failed transaction) Error Code Log error codes whenever there is a failure. Error codes can uniquely identify exact scenario therefore spend time defining them in your application. Best way is to define enum of ErrorCodes like below public enum ErrorCodes INVALID_EMAIL(1); private int id; ErrorCodes(int id) this.id = id; public int getId() return id; Elapsed Time - Time Taken to Finish Transaction Log the total time take by a transaction. It will help you easily identify the transactions that are slow. Elapsed Time of Each Major Component in Transaction If you transaction is made of multiple steps, you must also include time take for each step. This can narrow down your problem to the component that is performing slow.  I hope you find these tip useful. Please share with us anything missed in this page.

[thahxa]

between this and log4j is there anything minecraft kids can't do

mine craft seems like a good thing for youngsters actually. it’s creative and non violent and social to a degree. do they do a good job making sure it is safe

[infernovm]

Open-source Styrolite project aims to simplify container runtime security

Today Edera launched a new open-source project called Styrolite to bring tighter controls to the interactions between containers and Linux kernel namespaces, at a layer below where Open Container Initiative (OCI) runtimes like containerd operate. While software supply chain security incidents like Log4j and XZ Utils have dominated the container security headlines in recent years, the container…