On parle de boite noire lorsqu’on interagit avec un élément en lui envoyant des données et en en recevant en retour (in/out), sans connaître sa tambouille interne.

Pour le commun des mortels, c’est le cas d’à peu près tout ce que vous utilisez.
Une recherche Google : vous envoyez vos mots clés, vous recevez une page de résultats. Mais Google ne dévoile pas comment ils construisent cette page de résultat, quels sont les critères qui déterminent le premier, le second, etc.
Votre CB : vous tapez votre code, le paiement est accepté, sur votre compte la somme est débitée. Mais vous ne savez pas comment la carte vérifie votre code ni comment elle transmet à la banque l’ordre de paiement.
Votre progiciel de compta :  vous lui rentrez des factures, et il sort des nombres agrégés, qui normalement sont bons ... normalement.

Mais ça pose une question fondamentale en sécurité, qui fait couler de l’encre depuis des décennies : comment être certain qu’un dispositif est sûr si on ne sait pas comment il fonctionne ?
Face à cette question, les partisans de la «sécurité par l’obscurité» (dont l’autre nom connu dans le milieu de la cybersécurité est : les débiles) arguent que «si on ne peut pas voir comment ça fonctionne, les pirates non plus, donc même s’il y avait des vulnérabilités, ils ne les trouveraient pas». En d’autres termes, un système est supposé sécurisé tant qu’on n’a pas fait la preuve du contraire.
Le camp d’en face, les partisans du principe de Kerckhoffs, refusent cette inversion de la preuve et revendiquent qu’un système ne peut être considéré comme sécurisé que s’il en a fait positivement la preuve. Ils disent aussi de partir du scénario le moins favorable, à savoir «l’adversaire connait le système», comme hypothèse de base pour évaluer si un système est robuste.

La réponse à ce débat a été tranchée il y a longtemps (empiriquement et théoriquement) : la sécurité par l’obscurité ça ne marche pas !
D’une part, on finit toujours par tomber sur un adversaire qui sait comment le système fonctionne. Et là toute la sécurité tombe d’un coup si c’était le seul garde fou.
Ensuite, il y a des techniques d’attaque en aveugle (en blind), comme le fuzzing ou le reverse engineering, qui permettent de dévoiler le comportement interne de la cible. Donc ça met plus de temps, mais on finit par lever l’obscurité.

Ce qui fait que ce débat continue d’agiter les acteurs du domaine c’est que ce n’est malheureusement pas très compatible avec les réalités économiques du marché, et partiellement pas avec les réalités militaires.
En effet, en tant qu’éditeur d’une solution informatique quelconque, vous n’avez pas intérêt à rendre public le fonctionnement de votre produit. Sinon tous vos concurrents pourront vous copier et (ça dépend des cas) n’importe qui pourrait utiliser votre produit gratuitement.
Dans le secteur militaire vous avez besoin que vos outils soient sécurisés, mais aussi que ce soient des boîtes noires pour les autres nations. Car moins ils en savent sur votre fonctionnement, plus grand sera l’effort nécessaire pour vous déstabiliser.
Enfin, il existe des tas d’outils open source dont n’importe qui peut vérifier le fonctionnement, mais qui sont pourtant blindés de vulnérabilités. Tout simplement car personne n’a pris le temps d’en auditer la sécurité. En effet, ça requière du temps et des compétences peu répandues (donc c’est rare que les gens le fassent gratuitement).

Le compromis qui se dégage c’est que quand on a vraiment besoin de savoir qu’un logiciel est sécurisé (car il va être utilisé pour des opérations critiques par exemple), on en montre le code source seulement à l’État.
En effet, un état n’est généralement pas un concurrent de l’éditeur. L’idée c’est que l’état va homologuer certains laboratoires spécialisés (en France ce sont les CESTI) aptes à éprouver la sécurité d’un composant (matériel ou logiciel).
Ainsi l’éditeur peut conserver son code fermé, tout en ayant pu démontrer son niveau de sécurité via un tiers étatique (qui lui a eu accès au code source).
C’est pas mal, mais trop cher pour les petits éditeurs (et donc hors de portée des projets gratuits) et ça couvre un minuscule pourcentage des programmes utilisés dans les faits.

Certains éditeurs mènent des audits internes (ou par des tiers indépendants) de leurs applications pour prévenir l’introduction de vulnérabilités. Notamment car les vulnérabilités, ça finit par être exploitées et quand ça arrive, c’est mauvais pour la réputation.
Mais ça reste une démarche très opaque dont le périmètre réel et les détails techniques sont rarement rendus publics.

Par extension, le terme blackbox désigne aussi une façon, parmi trois, de tester la sécurité d’une cible :

• blackbox : vous n’aurez aucune information sur la cible, comme un adversaire venant d’Internet et externe à l’entité
• greybox : vous aurez un compte utilisateur, comme le cas où un utilisateur est hostile, déloyal ou bien qu’il s’est fait voler son compte par un pirate
• whitebox : vous aurez accès à tout le fonctionnement de la cible