ऐसे ज्ञात बगों के साथ सॉफ्टवेयर का जारी किया जाना एक आम बात है जो गैर-महत्वपूर्ण माने जाते हैं अर्थात जो उत्पाद के साथ ज्यादातर उपयोगकर्ताओं के मुख्य अनुभव को प्रभावित नहीं करते हैं। चूंकि परिभाषा के अनुसार सॉफ्टवेयर उत्पादों में किसी भी संख्या में अज्ञात बग मौजूद हो सकते हैं, परीक्षण के दौरान मापन से बचे हुए संभावित बगों की संख्या का एक अनुमान प्राप्त किया जा सकता है; उत्पाद को जितनी देर तक परीक्षण या विकसित किया जाता है वह और अधिक विश्वसनीय हो जाता है ("अगर हमारे पास पिछले सप्ताह 200 बग थे तो इस सप्ताह हमारे पास 100 बग होने चाहिएं). ज्यादातर बड़ी सॉफ्टवेयर परियोजनाओं के पास "ज्ञात बग" की दो सूचियां होती हैं - एक वह जिसके बारे में सॉफ्टवेयर टीम को जानकारी होती है और दूसरी जिसके बारे में उपयोगकर्ताओं को बताया जाता है। यह तथ्यों का छिपाया जाना नहीं है बल्कि उपयोगकर्ता उत्पाद के आंतरिक कार्यप्रणाली पर ध्यान नहीं देते हैं। दूसरी सूची उपयोगकर्ताओं को उन बगों के बारे में जानकारी देती है जिन्हें मौजूदा रिलीज में या बिलकुल भी दूर नहीं किया गया है और एक वर्कअराउंड की पेशकश भी की जा सकती है।

बगों को दूर नहीं किये जाने के कई कारण होते हैं:

उपरोक्त को देखते हुए किसी वास्तविक जटिलता वाले एक पूरी तरह से बग-मुक्त सॉफ्टवेयर का लेखन अक्सर असंभव माना जाता है। इस प्रकार बगों को इनकी गंभीरता के आधार पर वर्गीकृत किया जाता है और कम-तीव्रता वाले गैर-गंभीर बगों को बर्दाश्त कर लिया जाता है क्योंकि वे अधिकांश उपयोगकर्ताओं के लिए सिस्टम के समुचित संचालन को प्रभावित नहीं करते हैं। नासा के एसएटीसी ने त्रुटियों की संख्या प्रति 1000 लाइनों के कोड (एसएलओसी) में 0.1 से भी कम करने में कामयाबी हासिल की थी लेकिन इसे किसी वास्तविक दुनिया के प्रोजेक्ट के लिए संभव नहीं समझा गया।

किसी बग की गंभीरता इसके ठीक करने के महत्त्व के बराबर नहीं होती है और दोनों का मापन और प्रबंधन अलग-अलग किया जाना चाहिए। एक माइक्रोसॉफ्ट विंडोज सिस्टम पर मौत का नीला स्क्रीन अपेक्षाकृत एक गंभीर होता है लेकिन अगर यह केवल चरम परिस्थितियों में होता है, खास तौर पर अगर ये अच्छी तरह उपचारित और परिहार्य होते हैं, किसी आइकन द्वारा अपने कार्य का सही प्रतिधिनित्व नहीं किये जाने की तुलना में इसमें सुधार किया जाना कम महत्वपूर्ण हो सकता है जो हालांकि पूरी तरह सौंदर्य से संबंधित है लेकिन यह हर दिन हजारों उपयोगकर्ताओं को भ्रमित कर सकता है। यह संतुलन ज़ाहिर तौर पर कई कारकों पर निर्भर करता है; विशेषज्ञ उपयोगकर्ताओं को नौसिखियों से अलग उम्मीदें रहती हैं, एक ऊँचे दर्जे का बाजार एक सामान्य उपभोक्ता बाजार और इसी तरह के अन्य बाजारों से अलग होता है। एक बेहतर संतुलन प्राप्त करने के लिए कुछ सॉफ्टवेयर डेवलपर एक औपचारिक "बग ट्राइएज" प्रक्रिया (चिकित्सा शब्दावली को लेकर) का उपयोग करते हैं जिसमें प्रत्येक नए बग को इसकी गंभीरता, आवृत्ति, जोखिम और अन्य पूर्व-निर्धारित कारकों के आधार पर एक प्राथमिकता दी जाती है।

एरिक एस. रेमंड द्वारा लाइनस लॉ के रूप में प्रचारित एक विचारधारा कहती है कि अन्य सॉफ्टवेयर की तुलना में लोकप्रिय ओपन-सोर्स सॉफ्टवेयर में कम या कोई बग नहीं होने के मौके ज्यादा होते हैं क्योंकि "अधिक ध्यान देने पर, सभी बग हल्के होते हैं". इस दावे को विवादित करार दिया गया है, हालांकि: कंप्यूटर सुरक्षा विशेषज्ञ एलियास लेवी ने लिखा है कि "जटिल, कम स्पष्ट और अप्रलेखित स्रोत कोड में कमजोरियों को छिपाना कहीं आसान होता है" क्योंकि "यहां तक कि अगर लोग कोड की समीक्षा करते है तो इसका मतलब यह नहीं होता है कि वे ऐसा करने के लिए योग्य होते हैं।"

इंजीनियरिंग प्रबंधन के किसी अन्य भाग की तरह बग प्रबंधन सावधानी पूर्वक और समझदारी से किया जाना चाहिए क्योंकि "जिसका मापन होता है उसे ही ठीक किया जाता है" 
और शुद्ध रूप से बगों की गिनती द्वारा प्रबंधन अनपेक्षित परिणाम दे सकता है। उदाहरण के लिए, अगर डेवलपरों को उनके द्वारा ठीक किये गए बगों की संख्या के आधार पर पुरस्कृत किया जाता है तो वे स्वाभाविक रूप से -- सबसे कठिन और संभवतः सबसे जोखिमपूर्ण और सबसे महत्वपूर्ण बग को अंतिम संभव पलों के लिए छोड़कर सबसे आसान बग को पहले ठीक करेंगे ("मेरे पास अपनी सूची में एक मात्र बग है लेकिन यह "सूरज को पश्चिम से उगाने" की बात करता है). अगर प्रबंधन की प्रवृत्ति ठीक किये गए बगों के आधार पर पुरस्कृत करने की है तो कुछ डेवलेपर यह जानते हुए भी कि वे इन बगों को बाद में ठीक कर सकते हैं और इसके लिए पुरस्कृत किये जा सकते हैं, शीघ्रता से लापरवाह कोड लिख सकते हैं जबकि सावधान, संभवतः "धीमे" डेवलपरों को उन बगों के लिए कभी पुरस्कृत नहीं किया जाता है जो वहां कभी मौजूद ही नहीं थे।

बचाव
शब्द-व्युत्पत्ति
सुरक्षा संबंधी कमजोरियां
बग प्रबंधन