The Big Fuzz Theory: The Dark Fuzz Rises

Table Of Content


Alright, folks! Guess you've learned too much stuff by now, mastered the methods, and are all set to dive a little more deeper. But before we get our hands more nasty, there's a little something we've got to address. This final hurdle is an equal opportunity mischief maker - it doesn't matter whether you're a seasoned developer who types at lightning speed code, or a steadfast security engineer who wards off cyber threats with the finesse of a digital ninja. But just Strap in, wait for the speed bump to hit in, adjust your spectacles, and let's tackle this last challenge on our journey. Onwards and upwards, team!

Let’s discuss the hurdle!

Understanding how people think, especially in the realm of development and testing, is a complex matter. Coming from a testing background myself, I often ponder how I might have performed had I been a developer. But that's a subjective thought. What's clear, however, is the bias that can creep into auditing or testing. It's not a good sign.

Imagine receiving a lengthy codebase with no testing. It's a disaster waiting to happen. Or perhaps there are tests, but they appear to be mere formalities, lacking substance and rigor. Why would this happen? Let me elucidate.

Consider this perspective: "If I were a developer, I would have crafted something with all my heart, treating it like my own child. Having invested so much effort, how could I possibly leave any bugs or errors in it?" This bias leads to a mindset where, when writing tests, one already assumes everything is working perfectly. The tests become a mere process, a box to tick, rather than a genuine effort to ensure quality. The optimism is lost.

This story isn't unique to developers. It's a tale that resonates with SQA engineers and security engineers alike. The biases, the assumptions, and the complacency can manifest in many forms, but the underlying theme remains the same. The belief that one's work is flawless can lead to a lack of critical evaluation, and that's where the real danger lies. Whether it's development, quality assurance, or security, the challenge is to overcome these biases and approach the task with an open, critical, and unbiased mind.

More Explanation!

The Dark Fuzz Rises

Let me describe each of them by role!!


Confirmation Bias: Developers may fall into the trap of confirmation bias, where they interpret information in a way that confirms their pre-existing beliefs or hypotheses. For example, they may focus more on testing code written by a colleague or sometimes most of developers google, point is code can have a history of errors, maybe he doesn't know, thereby neglecting other potentially problematic areas.

Congruence Bias: This bias leads developers to validate only the expected behavior, ignoring potential negative or alternative outcomes. This narrow focus can lead to missed defects and vulnerabilities.

Software Quality Assurance (SQA) Professionals

Resemblance Bias: SQA professionals may judge a situation based on the resemblance of a similar situation. For instance, they may assume that web applications will have similar kinds of errors, leading to a narrow focus and potentially missing unique or unexpected defects.

In-Attentional Blindness: This bias can cause testers to miss the most obvious defects when they are not specifically looking for them. For example, in an enhancement project, focusing solely on a newly developed feature may lead to overlooking critical integrations elsewhere.

Negativity Bias: This refers to giving more psychological weight to bad experiences than good ones. In testing, this may manifest as an unwillingness to sign off on a software for production, focusing only on uncovered defects and ignoring the overall quality and readiness of the product.

Web2 Security Engineers

Bandwagon Effect: Security engineers may be influenced by the collective beliefs of their peers. If a group believes that a particular module or system is secure, others may unconsciously adopt the same belief, leading to a lack of scrutiny and potential security risks.

Confirmation Bias: Similar to developers, security engineers may also suffer from confirmation bias, focusing on areas that align with their preconceived notions and neglecting others that may pose significant security threats.

Security Auditors

Congruence Bias: Auditors may fall into the trap of focusing on one feature and try to break it and not consider other threats only considering the same threat and failing to explore alternative scenarios. This can lead to a lack of comprehensive evaluation and potential oversights in compliance and risk assessment. This can also happen when they don't have enough time to finish, I guess this is why we should not consider anything 100% secure.

In-Attentional Blindness: Auditors may overlook significant issues if they are not specifically within the scope of their current focus. This can lead to incomplete audits and potential regulatory or compliance failures.


Cognitive biases are inherent in human nature and can significantly impact everyone within the software development and testing process. 

Point is how to get over this while testing, specifically formal verification. The method is very simple. Try not to be, believe me it will lead to more accurate and reliable outcomes in software development, testing, security, and auditing.

Let's forge ahead and I will explore you with this remarkable technique that promises to be a game-changer for developers and testers alike. It will help you to transcend your biases, it paves the way for a substantial enhancement in code quality. This isn't just a method; it's a revolution, a key to unlock potential. In the ever-evolving landscape of software development, this technique stands as a beacon, guiding professionals to a future where code isn't just written but written with precision. It's time to embrace this new era, where biases are left behind, and quality takes center stage.

Let me introduce Fuzz Driven Development (FDD)

it’s not merely a methodology; it's a paradigm shift in the software development lifecycle. By incorporating fuzz testing at the inception of development, FDD fundamentally alters the outcome, transcending conventional methodologies. It provides a solid and unyielding framework for quality assurance and security validation, establishing a new benchmark in the pursuit of excellence and resilience in software engineering.

Now the question is "How can one overcome his bias using FDD?

Overcoming Biases with FDD

Objective Evaluation through Randomized Inputs: FDD employs stochastic processes to generate a plethora of test cases, ranging from the mundane to the downright bizarre. It's like throwing a party for your code and inviting guests from every corner of the input space. You never know who might show up, but that's the fun part!

Automated Continuous Testing: Automation in FDD is not just a convenience; it's a relentless pursuit of perfection. It's like having a robotic comedian that never sleeps, continually testing your code's sense of humor with an endless stream of punchlines (or in this case, edge cases).

Security-Centric Approach: FDD's focus on security is akin to a digital bodyguard for your code, always on the lookout for potential threats. It's not paranoid; it's just thorough. After all, in the world of code, trust issues are considered a virtue.

Collaborative Cross-Functional Teams: FDD fosters collaboration between developers, testers, and security experts. It's like a tech symphony where everyone plays a different instrument but follows the same score. The result? Harmonious code that sings rather than stings.

Adaptive Testing Methodologies: FDD is not set in stone; it's more like a jazz improvisation, adapting to the ever-changing rhythm of vulnerabilities and attack vectors. It's about staying one step ahead of the bad guys, even if it means dancing to a different beat.

Lets jump to the conclusion of this article!

Fuzz Driven Development is not just a buzzword; it's a hell of a technique, The methodology, or a best practice that helps developers and testers overcome their biases. It's about looking at code not just as lines on a screen but as a living, breathing entity that needs to be challenged, prodded, and occasionally tickled with unexpected inputs.

In the grand show of software development, FDD is the spotlight that shines on the hidden corners, revealing the unseen and making the improbable probable. It's a journey into the unknown, with a roadmap written in algorithms, a compass guided by randomness, and a destination defined by quality.

So, dear readers, embrace the chaos, dance with the unexpected, and let FDD be your guide to become the best. After all, in the world of Fuzz Driven Development, the only constant is surprise, and the only bias is towards excellence.

More Audits

LightLink Token Transfer Bridge Architecture Threat Modeling

This comprehensive threat analysis report provides an in-depth review of potential security vulnerabilities within the LightLink Token Transfer Bridge Architecture. Through rigorous application of both the STRIDE and ABC threat modeling frameworks, the report identifies key system weaknesses and offers strategic mitigation recommendations.

Polkalokr Matic Bridge Contract Audit Report

The analysis indicates that the contracts audited are secured and follow the best practices.
Our team performed a technique called “Filtered Audit”, where the contract was separately audited by two individuals. After their thorough and rigorous process of manual testing, an automated review was carried out using Slither, and Manticore. All the flags raised were manually reviewed and re-tested.

Revisiting Ethereum Classic in Light of the London Hard Fork

The successful upgrade of the London Hard Fork is a big difference from the fork leading to Ethereum Classic that took place back in 2016. However, despite their divergence, both are milestones in the Ethereum world- guaranteed to have lasting impacts on the blockchain as we know it. Read more to find out the circumstances surrounding each hard fork and the role they may play in shaping Ethereum's future.

Web2 Security vs Web3 Security: An Innovative Adaptation?

Web 3.0 is a semantic web where it promises to establish information in a better-existing way than any current search engine can ever attain. Web 3.0 promotes four concepts which mainly are authenticity, i.e, every piece of information existing on the internet is a fact or derived from a fact. Integrity, willingness to abide by moral principles, and ethical values. Transparency, the data present on the internet is accessible for every user to witness. Lastly, Confidentiality which is achieved by Blockchain technology, where every user’s identity is anonymous, making it secure. 

Chainpals Token Audit Report

The main contract is called Chainpals Token. The minting and transfer of the complete supply is done during deployment. This means new tokens can only be minted if the old ones are burnt.

Consumer Privacy & Data Breach Part II - Is Web 3.0 The Cure?

The last few years have resulted in consumer privacy and data breach issues. Those issues have made the users conscious and ambiguous about the data on the internet. Read more in this blog.

SushiSwap - April 9, 2023

On April 9, 2023, SushiSwap suffered a security breach which led to a loss of over $3.3 million. The attack exploited a flaw in the RouteProcessor2 contract of SushiSwap's router processor. The fallout was felt across several major chains that had previously authorized the RouteProcessor2 contract.

Phase Protocol Audit Report

Phase Protocol is a NFT Marketplace infrastructure built on Solana Protocol, a reliable and scalable L1 solution. The on-chain Fundraising solution offered by DedMonke provides a crowdfunding experience to DeFi users.

Merlin DEX - April 26, 2023

In April 2023, Merlin DEX,a decentralized exchange (DEX) built on ZkSync, suffered a hack during a Liquidity Generation Event for its MAGE token, resulting in an estimated loss of $1.8 million from the protocol.

1 2 3 10
Designed & Developed by: 
All rights reserved. Copyright 2023